Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

An apparatus and methods of securely communicating a message between a
first device and a second device using a message specific identifier is
disclosed. The method begins by receiving the message and the message
specific identifier from the first device by the second device where the
message specific identifier is associated with one or more attributes
associated with the message and the first device. A decryption key
request is transmitted to a server in communication with the second
device, wherein the decryption key request is based upon the message
specific identifier received and a second device attribute. A decryption
key is received from the server, wherein the decryption key is based on
the message specific identifier and a stored random character set. The
encrypted message is then decrypted using the received decryption key.

Claims:

1-8. (canceled)

9. A method of securely communicating a message between a first device
and a second device using a message specific identifier, comprising the
steps of: receiving the message and the message specific identifier from
the first device by the second device, the message specific identifier
being associated with one or more attributes associated with the message
and the first device; transmitting a decryption key request to a server
in communication with the second device, wherein the decryption key
request is based upon the message specific identifier received and a
second device attribute; receiving a decryption key from the server,
wherein the decryption key is based on the message specific identifier
and a stored random character set; and decrypting the encrypted message
using the received decryption key.

10. The method of claim 9, wherein the one or more attributes associated
with the message specific identifier include at least one from the group
comprising a hardware address associated with the first device, a sender
address, a recipient address, a chronological attribute, a user ID
attribute, a password attribute, and a processing unit component ID
attribute.

11. The method of claim 9, wherein the second device attribute comprises
a media access control address associated with the second device.

12. The method of claim 9, wherein the receiving of the message and the
message specific identifier step comprises accessing the message and the
message specific identifier from the first device by the second device
only after a valid user ID and password attribute is provided by the
second device.

13. The method of claim 9 further comprising the step of destroying the
decryption key received after decrypting the encrypted message.

14. The method of claim 9, wherein the message specific identifier is an
information-based indicator that is unique with respect to the message
received.

15. The method of claim 9, wherein the receiving the decryption key step
comprises receiving the decryption key from the server only if the
decryption key request is valid.

16. The method of claim 15, wherein the receiving the decryption key step
further comprises receiving the decryption key from the server only if
the decryption key is valid compared to a validation key stored on the
server.

17-26. (canceled)

27. An apparatus for securely communicating a message between a plurality
of devices using a message specific identifier, comprising: a processing
unit within a recipient one of the devices; volatile memory coupled to
the processing unit, the volatile memory maintaining a user ID and a
password; a data communication interface coupled to the processing unit
and in operative communication with a server external to the recipient
device, the data communication interface providing the message and the
message specific identifier to the processing unit upon receipt from a
sending one of the devices, the message specific identifier being
associated with one or more attributes associated with the message and
the sending device; a memory storage coupled to the processor, the memory
storage maintaining a messaging application and a secure receiving
module; wherein, the processing unit is operatively configured, when
executing the secure receiving module, to access the message and the
message specific identifier only after the processing unit determines the
user ID and password are valid, cause the data communication interface to
transmit a decryption key request to the server, wherein the decryption
key request is based upon the message specific identifier received and a
recipient device attribute; receiving a decryption key from the server
via the data communication interface, wherein the decryption key is based
on the message specific identifier, a stored random character set in the
server accessible based upon the message specific identifier, and one of
a plurality of encryption key construction paradigms reside on the
server; and decrypting the message using the received decryption key.

28. The apparatus of claim 27, wherein the one or more attributes
associated with the message specific identifier include at least one from
the group comprising a hardware address associated with the sending
device, a sender address, a recipient address, a chronological attribute,
a user ID attribute, a password attribute, and a processing unit
component ID attribute.

29. The apparatus of claim 27, wherein the message specific identifier is
an information-based indicator that is unique with respect to the message
and the sending device.

30-33. (canceled)

34. The apparatus of claim 27, wherein the processing unit is further
operatively configured, when executing the secure receiving module, to
prompt the user to enter the user ID and the password.

35. The apparatus of claim 34, wherein the user ID and the password are
each types of login information based at least in part on one from a
group comprising biometric, numeric, alphabetic, and alphanumeric data.

36. The apparatus of claim 35, wherein the processing unit is further
operatively configured, when executing the secure receiving module, to
destroy the received decryption key after decrypting the message.

37. A computer readable medium on which is stored a set of executable
instructions for securely communicating a message between a plurality of
devices using a message specific identifier, which when executed on a
recipient one of the devices perform steps comprising: receiving the
message and the message specific identifier by the recipient one of the
devices, the message specific identifier being associated with one or
more attributes associated with the message and a sending one of the
devices; transmitting a decryption key request to a server in
communication with the recipient one of the devices, wherein the
decryption key request is based upon the message specific identifier
received and an attribute associated with the recipient one of the
devices; receiving a decryption key from the server, wherein the
decryption key is based on the message specific identifier and a stored
random character set; and decrypting the encrypted message using the
received decryption key.

38. The computer readable medium of claim 37, wherein the one or more
attributes associated with the message include at least one from the
group comprising a hardware address associated with the sending one of
the devices, a sender address, a recipient address associated with the
recipient one of the devices, a chronological attribute, a user ID
attribute, a password attribute, and a processing unit component ID
attribute.

39. The computer readable medium of claim 38, wherein the user ID
attribute is based at least in part on one from a group comprising
biometric, numeric, alphabetic, and alphanumeric data.

40. The computer readable medium of claim 38, wherein the password
attribute is based at least in part on one from a group comprising
biometric, numeric, alphabetic, and alphanumeric data.

41. The computer readable medium of claim 37, wherein the message
specific identifier is an information-based indicator that is unique with
respect to the message received.

42. The computer readable medium of claim 37, wherein the set of
executable instructions, which when executed on the recipient one of the
devices performs the further step of saving or destroying the received
decryption key according to a preference of the recipient one of the
devices.

Description:

FIELD OF THE DISCLOSURE

[0001] The present disclosure relates to systems, apparatus and methods in
the field of secure and encrypted communications and, more particularly,
for improved apparatus, systems and methods of secure communication using
a communication encryption BIOS based upon a message specific identifier.

BACKGROUND

[0002] The desire to securely communicate is rooted in the need for
confidentiality and secrecy. This need to communicate in a secure manner
reaches into and is involved in many aspects of society and industry.
Indeed, communicating via an electronic medium poses a variety of
increased threats and compromises that may expose some methods of
communication to the potential loss of confidentiality or rendering the
communication unsecure.

[0003] Using trusted and private networks may help improve the security of
communications, but use of such controlled communication pathways is
often costly and frequently impractical. Thus, computing and
communication devices, such as personal computers, smart phones, radios,
intelligent appliances, and other microprocessor-based communication
equipment, often transmit information over untrusted networks but still
desire the need to communicate information securely. Users of such
devices strive to maintain the security and proprietary nature of
communications in a variety of conventional ways, but there remains a
further need to securely communicate between devices using an untrusted
network.

SUMMARY

[0004] In the following description, certain aspects and embodiments will
become evident. It should be understood that the aspects and embodiments,
in their broadest sense, could be practiced without having one or more
features of these aspects and embodiments. It should be understood that
these aspects and embodiments are merely exemplary.

[0005] One aspect of the disclosure relates to a method of securely
communicating a message between a first device and a second device using
a message specific identifier. The method begins by assembling the
message specific identifier from one or more attributes associated with
the message and the first device. The attributes may include at least one
from the group comprising a hardware address associated with the first
device, a sending address, a recipient address, a chronological
attribute, a user ID attribute, a password attribute, and a processing
unit component ID attribute. Assembling the message specific identifier
may involve creating a hash of the attributes to form an
information-based indicator that is unique with respect to the message
and the first device.

[0006] The method then transmits an encryption key request to a server,
wherein the encryption key request is based upon the message specific
identifier. Next, an encryption key is received from the server, wherein
the encryption key is based on the message specific identifier and a
random character set. The message is encrypted using the key and the key
is destroyed before sending the encrypted message to the second device.

[0007] In another aspect of the disclosure, another method is described
for securely communicating a message between a first device and a second
device using a message specific identifier. The method begins by
receiving the encrypted message and the message specific identifier from
the first device by the second device, the message specific identifier
being associated with one or more attributes associated with the message
and the first device. The method transmits a decryption key request to a
server in communication with the second device. The decryption key
request is based upon the message specific identifier received and a
second device attribute, such as a device specific hardware identifier
or, more specifically, the second device's MAC address together with the
second device's validated user information such as one or several of a
user ID, password and other validation information components such as are
readily known to those practiced in the art. Next, the decryption key is
received from the server, wherein the decryption key is based on the
message specific identifier and a stored random character set maintained
on the server. The encrypted message may then be decrypted with the key.

[0008] In yet another aspect of the disclosure, another method is
described for securely communicating a message between a first device and
a second device using a message specific identifier. The method begins by
receiving an encryption key request from the first device, wherein the
encryption key request is based upon the message specific identifier
associated with a plurality of attributes associated with the message and
the first device. Next, the method parses the encryption key request and
the message specific identifier to provide an intermediate argument used
to enter a current random character set that is periodically generated
and stored into memory. The intermediate argument is associated with an
entry point in the current random character set. An encryption key is
then constructed from the current random character set and the entry
point of the current random character set associated with the
intermediate argument. The method then stores a data structure associated
with the message specific identifier and a random character set
identifier associated with the current random character set before
transmitting the encryption key to the first device.

[0009] And in yet another aspect of the disclosure, a method is described
for securely communicating a message between a first device and a second
device using a message specific identifier. The method begins by
receiving an encryption key request from the first device, wherein the
encryption key request is based upon the message specific identifier
associated with a plurality of attributes associated with the message and
the first device. Next, the method parses the encryption key request and
the message specific identifier to provide an intermediate argument used
to specify one of a plurality of BIOS resident encryption key
construction paradigms. An encryption key is then constructed from the
current random character set and the BIOS resident encryption key
construction paradigm. The method then stores a data structure associated
with the message specific identifier, the current random character set
identifier and the specified BIOS resident encryption key construction
paradigm before transmitting the encryption key to the first device.

[0010] The method may further include receiving from the second device a
decryption key request and a second device attribute, such as the second
device's MAC address and/or together with the second device's validated
user information, such as one or several of a user ID, password and other
validation information components such as are readily known to those
skilled in the art, and where the decryption key request is based upon
the message specific identifier. After determining whether the decryption
key request is valid based upon the second device attribute, the method
may access the recorded data structure to locate the random character set
identifier based upon the message specific identifier. The method may
then construct a decryption key from the random character set associated
with the located random character set identifier and transmit the
constructed decryption key to the second device.

[0011] Another aspect of the disclosure involves an apparatus for securely
communicating a message between a plurality of devices using a message
specific identifier and a server coupled to the devices. The apparatus
comprises a processing unit within the server, volatile memory coupled to
the processing unit, a data communications interface coupled to the
processing unit and a memory storage also coupled to the processing unit.
The data communication interface is in operative communication with the
devices and provides an encryption key request and a decryption key
request to the processing unit upon respective receipt of such requests
from one of the devices. The encryption key request and the decryption
key request are based upon the message specific identifier, which is
associated with a plurality of attributes associated with the message and
a sending one of the devices. The memory storage maintains a secure
communications management module and a plurality of random character
sets. Each of the random character sets is periodically generated by the
secure communications management module and stored on the memory storage.

[0012] The processing unit is configured, when executing the secure
communication management module, to respond to the encryption key request
and decryption key request. More specifically, in response to the
encryption key request, the processing unit is operative to parse the
encryption key request and the message specific identifier to provide an
intermediate argument used to enter a current one of the random character
sets maintained on the memory storage, where the intermediate argument
associated with an entry point in the current one of the random character
sets; to parse the encryption key request and the message specific
identifier to provide an intermediate argument used to specify one of a
plurality of BIOS resident encryption key construction paradigms; and to
construct an encryption key from the current one of the random character
sets and the entry point of the current one of the random character sets
associated with the intermediate argument and the specified BIOS resident
encryption key construction paradigm; record a data structure on the
memory storage, where the data structure is associated with the message
specific identifier and a random character set identifier associated with
the current one of the random character sets and an identifier of the
specified BIOS resident encryption key construction paradigm; and provide
the encryption key to the data communication interface and cause the
encryption key to be transmitted to the one of the devices that sent the
encryption key request.

[0013] The processing unit is further operative, in response to the
decryption key request, to determine whether the decryption key request
is valid. If the decryption key request is determined to be valid, the
processing unit is further operative to access the stored data structure
on the memory storage to locate the random character set identifier and
identifier of the relevant BIOS resident encryption key construction
paradigm based upon the message specific identifier; construct a
decryption key from the relevant BIOS resident encryption key
construction paradigm and the one of the random character sets associated
with the located random character set identifier; and provide the
constructed decryption key to the data communication interface and cause
the decryption key to be transmitted to the another of the devices that
send the decryption key request.

[0014] Additional advantages of this and other aspects of the disclosed
embodiments and examples will be set forth in part in the description
which follows, and in part will be obvious from the description, or may
be learned by practice of the invention. It is to be understood that both
the foregoing general description and the following detailed description
are exemplary and explanatory only and are not restrictive of the
invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The accompanying drawings, which are incorporated in and constitute
a part of this specification, illustrate several embodiments according to
one or more principles of the invention and together with the
description, serve to explain one or more principles of the invention. In
the drawings,

[0016] FIGS. 1A-1C are exemplary block diagrams of exemplary
configurations of a server and two devices in communication with each
other in accordance with an embodiment of the invention;

[0017]FIG. 2 is a more detailed diagram illustrating exemplary hardware
and software components within a device used for communication as shown
in FIGS. 1A-1C;

[0018]FIG. 3 is a more detailed diagram illustrating exemplary hardware
and software components within a server used for communication as shown
in FIGS. 1A-1C;

[0019] FIG. 4 is a flowchart diagram illustrating exemplary steps of a
method performed by a sending device when a message is generated and sent
in a secure manner in accordance with an embodiment of the invention;

[0020]FIG. 5 is a flowchart diagram illustrating exemplary steps of a
method performed by a receiving device when a message is received and to
be decrypted in a secure manner in accordance with an embodiment of the
invention;

[0021]FIG. 6 is a flowchart diagram illustrating exemplary steps of
methods performed by a server used to facilitate encryption and
decryption of a message being sent and received in a secure manner in
accordance with an embodiment of the invention;

[0022]FIG. 7 is a message flow diagram illustrating exemplary devices and
servers used in an exemplary BIOS implemented embodiment in accordance
with principles of the invention.

DESCRIPTION OF THE EMBODIMENTS

[0023] Reference will now be made in detail to exemplary embodiments.
Wherever possible, the same reference numbers are used in the drawings
and the description to refer to the same or like parts.

[0024] In general, the following describes various embodiments of systems
and methods for securely communicating between two devices using a
message specific identifier are described herein. The devices may
communicate a message directly with each other and generally make
requests of a server when creating, encrypting and sending the message
and/or when receiving, decrypting, and reading the message. As such, one
aspect of an embodiment has encryption and decryption key construction
being organic and specific to the particular message being encrypted or
to be decrypted. More specifically, an embodiment may create a hash of
particular message attributes to form an information-based indicator that
is unique with respect to the message, and that indicator (more generally
referenced as a message specific identifier) is used as part of
encryption/decryption key construction as opposed to a server arbitrarily
assigned key and or an equally arbitrarily assigned server originated
message identifier.

[0025] One of skill in the art will appreciate that, generally, a device
is considered herein as a communication component. Examples of such a
device may be a computer, radio, or other processor-based component or
appliance of a larger system that requires or desires components to
securely communicate over untrusted networks. Further examples of devices
include, but are not limited to, cell phones, smart phones, computers,
laptops, other handheld devices (such as a PDA or tablet), televisions,
or any other processor-based appliances that allow a user to formulate
messages and communicate that message with a server and another user on
another device.

[0026] FIGS. 1A-1C are block diagrams of exemplary configurations of a
server and two devices in communication with each other in accordance
with different embodiments of the invention. Referring now to FIG. 1A, a
first configuration 100 is disclosed that includes two devices 105a, 105b
and a server 110. Devices 105a, 105b are shown in direct communication
with each other while server 110 is shown having independent
communication paths to each of device 105a and device 105b. FIG. 1B
illustrates an alternative configuration, such as a local data
communication network, where each of device 105a, device 105b and server
110 are coupled to a network or other data communication bus 115 at
specific points. FIG. 1C illustrates yet a further configuration where
the network 120, which communicatively couples (i.e., allows
communication between devices or the server), is implemented in a less
formal network or data communication topology, such as the Internet.

[0027] However, in each of these device/server configurations, the
communicating entities are set up so that one device may send a signal to
another device or to the server. In this manner, the server may be used
to facilitate communication of a message from one device to the other
device. Communication may be implemented in these configurations over a
variety of communication networks or paths involving hard wired
structures (e.g., telecommunication lines, telecommunication support
structures and telecommunication processing equipment, etc.), wireless
structures (e.g., antennas, receivers, repeaters, etc.) and a combination
of both depending upon the desired implementation of a communication
system that may employ an embodiment of the present invention.

[0028]FIG. 2 is a more detailed diagram illustrating exemplary hardware
and software components within an exemplary device used for communication
as shown in FIGS. 1A-1C. Referring now to FIG. 2, exemplary device 105a
is shown in more detail as several coupled components comprising a
processing unit 200, a user interface 205, data communication
interface/network interface 210, memory storage 215 and volatile memory
220. In general, processing unit 200 performs basic and complex
computations and executes operational and application program code and
other program modules within the device 105a. User interface 205, coupled
to the processing unit 200, allows a user of the device to enter
information, such as the content of a message to be sent to another user.
Data communication interface/network interface 210 is coupled to the
processing unit 200 and may include other hardware (not shown) for
operatively coupling the device to a specific communication path, such as
a transmitter and antenna for coupling device 105a to a wireless
communication path or a LAN/Ethernet interface card for coupling device
105a to a wired local area network, such as network 115 of FIG. 1B.

[0029] Volatile memory 220 and memory storage 215 are each coupled to the
processing unit 200 as well. Both memory components provide elements used
by processing unit for maintaining and storing information and data used
when securely communicating with other devices. In the embodiment shown
in FIG. 2, memory storage 215 maintains a variety of program code (e.g.,
operating system 225, messaging application 230, secure sending module
235, and secure receiving module 240) and other data (e.g., device
specific data, which may include a device specific hardware identifier
such as a media access control (MAC) address). Memory storage 215 is a
computer readable medium on which information (e.g., executable
code/modules, user data, stored messages, etc.) may be kept in a
non-volatile manner. Examples of such memory storage 215 may include a
hard disk drive, ROM, flash memory or other media structure that allows
longer term storage of information. In contrast, volatile memory 220 is
typically a random access memory (RAM) structure used by processing unit
200 during operation of the device. In the embodiment of FIG. 2, volatile
memory 220 is populated after boot-up of the device 105a with an instance
of operating system 225, various applications 250 (such as messaging
application 230), and program modules that help facilitate securely
communicating with other devices (e.g., secure sending module 235 and
secure sending module 240). As will be explained in more detail below and
herein, volatile memory 220 may also maintain a key 255, which is
typically not stored in memory storage 215 and may be in the form of an
encryption key (when sending a message and using the secure sending
module 235) or the form of a decryption key (when decrypting a message
received using the secure receiving module 240).

[0030] During relevant operation of device 105a shown in FIG. 2, messaging
application 230 operates as a software application that creates and
transmits a message to another device and that receives a message from
another device. In the embodiment illustrated, messaging application 230
interfaces with the secure sending module 235 when creating and
transmitting the message and interfaces with the secure receiving module
240 when receiving and decrypting the message from another device. Secure
sending module 235 and secure receiving module 240 may be implemented as
distinct program code modules with respect to the messaging application
or may be integrated within the messaging application itself.

[0031] In the illustrated embodiment of FIG. 2, modules 235 and 240 gather
information in the form of message and particular device attributes, and
provide access to a server using a message specific identifier created
from the message and device attributes. The server access provided by
these modules 235, 240 facilitates key generation and provides either an
encryption key with module 235 or a decryption key with module 240 from
the server.

[0032] In other embodiments, such as the embodiment illustrated in FIG. 7
and described in more detail below, modules 235 and 240 may be
implemented in lower level software/firmware (e.g., BIOS interface
sending module 735 and BIOS receiving module 740, respectively) operating
within device 105a. Such lower level software/firmware modules may be
implemented as a BIOS level of functionality that controls certain basic
functions within the device. In other embodiments, one skilled in the art
will appreciate that similar functionality maybe implemented in specially
optimized hardware (e.g., a particular application specific integrated
circuit (ASIC) having the same functionality as secure sending module 235
and secure receiving module 240), discrete logic, or a combination of
hardware and firmware depending upon requirements of the device, such as
power, processing speed, cost, space, etc.

[0033]FIG. 3 is a more detailed diagram illustrating exemplary hardware
and software components within a server used for communication as shown
in FIGS. 1A-1C. Referring now to FIG. 3, exemplary server 110 is shown in
more detail as several coupled components comprising a processing unit
300, a data communication interface/network interface 315, memory storage
305 and volatile memory 310. Those skilled in the art will appreciate
that exemplary server 110 may be implemented with a single processor or
may be implemented as a multi-processor component that communicates with
devices, such as device 105a or device 105b. Server 110 may be
implemented as a distributed server or server farm that logically allows
multiple distinct components to function as a server from the perspective
of the device (e.g., device 105a or 105b). Likewise, while the embodiment
shown in FIG. 3 illustrates a single memory storage 305, exemplary server
110 may deploy more than one memory storage media and do so in differing
forms (e.g., conventional hard disk drives, solid state memory such as
flash memory, optical drives, RAID systems, cloud storage configured
memory, network storage appliances, etc.).

[0034] In general, processing unit 300 performs basic and complex
computations and executes operational and application program code and
other program modules within the server 110. While not shown in the
illustrated embodiment, server 110 may include a user interface, such as
an input device (e.g., keyboard, mouse, tablet) and a display unit. Data
communication interface/network interface 315 is coupled to the
processing unit 300 and may include other hardware (not shown) for
operatively coupling the server to particular devices and networks.

[0035] Processing unit 300 is coupled to volatile memory 310 and memory
storage 305. Both memory components associated with server 110 provide
elements used by the processing unit 300 for maintaining and storing
information and data used when facilitating requests from devices when
securely communicating between devices. In the embodiment shown in FIG.
3, memory storage 305 maintains a variety of program code (e.g.,
operating system 320, request handling module 330, secure communication
management module 325) and other server created data structures (e.g.,
current and previous random character sets, message specific identifiers
for particular messages and identifiers for particular random character
sets). Like memory storage 215, memory storage 305 is a computer readable
medium on which information (e.g., executable code/modules, data
structures, etc.) may be kept in a non-volatile manner.

[0036] Volatile memory 310 is typically a RAM structure used by processing
unit 300 during operation of the server. In the embodiment of FIG. 3,
volatile memory 310 is populated after boot-up of the server 110 with an
instance of operating system 320, various applications 340 (such as
request routing module 330 and secure communication management module
325), and data and other server created data structures 335. During
operation of exemplary server 110, request routing module 330 operates to
received a key request and validate the request, while the secure
communication management module 325 is responsible for
encryption/decryption key generation for valid requests. For example,
request routing module 330 may receive an encryption key request from a
device and, as a level of security, determine if the request is valid.
This may be done by reviewing the received message specific identifier
provided as part of the encryption key request. Once the request routing
module 330 confirms the request is valid and from a registered device,
the request is then handled by the secure communication management module
325 at a lower level. As such, the embodiment of FIG. 3 implements
modules 325 and 330 in a layered approach, but those skilled in the art
will appreciate that other embodiments may implement request handling,
validation, and encryption/decryption key construction in a single module
or with other software code sections.

[0037] In other embodiments, such as the embodiment illustrated in FIG. 7
and described in more detail below, modules 325 and 330 may be
implemented as part of lower level software/firmware (e.g., BIOS software
725) operating within Communications Encryption Server 110. As with other
embodiments, one skilled in the art will appreciate that similar
functionality in server 110 may be implemented in specially optimized
hardware (e.g., a particular application specific integrated circuit
(ASIC) having the same functionality as modules 325 and 330), discrete
logic, or a combination of hardware and firmware depending upon
requirements of the server, such as power, processing speed, number of
processors, number of memory storage units coupled to the processor(s),
cost, space, etc.

[0038] Further details on the operation of particular embodiments are
illustrated through general flowcharts of FIGS. 4-6. FIGS. 4 and 5 are
flowchart diagrams illustrating exemplary steps of a method performed by
a device when a message is generated and sent in a secure manner or
received and decrypted in a secure manner, respectively. FIG. 6 is a
flowchart diagram illustrating exemplary steps of methods performed by a
server used to facilitate encryption and decryption of a message being
sent and received in a secure manner in accordance with an embodiment of
the invention.

[0039] Referring now to FIG. 4, method 400 begins at step 405 by composing
a message. In one embodiment, this may be accomplished by messaging
application 230. At step 410, when the user desires to send the composed
message, the user is prompted for login information. In one embodiment,
the secure sending module 235 prompts the user to enter login information
in the form of a user ID and password (such as a PIN). The user ID and
password may be based in part at least on biometric, numeric, alphabetic,
alphanumeric or a combination of such characteristics.

[0040] At step 415, the method assembles a message specific identifier
from one or more attributes associated with the message, and the first
device. In one embodiment, the attributes may include a hardware address
associated with the first device, a sending address of the message, a
recipient address of the message, a chronological attribute, a user ID
attribute, a password attribute, and a processing unit component ID
attribute. The first address may be a media access control (MAC) address.
The chronological attribute may be a time stamp, a date stamp or a
time/date stamp associated with the message. The user ID and password
attributes may be based in part at least on biometric, numeric,
alphabetic, alphanumeric or a combination of such characteristics or
merely the first device's pass fail validation of same or the first
device's request to the server that it initiate, request and or perform
user validation. In more detail, assembling the message specific
identifier from one or more of such attributes may involve creating a
hash of the attributes to form an information-based indicator that is
unique with respect to the message and the first device. In this manner
and as described herein, key construction may occur that is predicated on
such a message unique identification organic to the message.

[0041] At step 420, the method generates an encryption key request (EKR)
that incorporates the message specific identifier. At step 425, the EKR
is transmitted by the device to a server, which processes the EKR as
denoted in FIG. 6. In response to the EKR, an encryption key is received
by the device from the server at step 430. The encryption key, as
explained in more detail with reference to FIG. 6, is based upon the
message specific identifier, a random character set generated and stored
within the server. The encryption key is generated using one of a
plurality of encryption key construction methods, such as AES, DES or
other common encryption methods, algorithms or paradigms known to one
skilled in the art. The particular encryption key construction method may
be implemented in one or more software modules on the server and may be
selected based upon the content of the message specific identifier or,
more specifically, an intermediate argument related to the message
specific identifier.

[0042] At step 435, the message is encrypted with the encryption key. In
the illustrated embodiment of FIG. 2, the secure sending module encrypts
the message received from server 110, and as noted in FIG. 4, step 440,
destroys the encryption key on the sending device. This destructively
deletes all trace of the encryption key from the sending device. At step
445, the encrypted message and message specific identifier are provided
to the messaging application, such as application 230. In embodiments
where the secure sending module and the messaging application are
integrated into a single unit, there is no need to push up a layer from
the secure sending module. Finally, at step 450, the encrypted message
and message specific identifier are sent or transmitted to the intended
recipient device.

[0043] When securely receiving a message, such as through the exemplary
method illustrated in FIG. 5, the device also interfaces with the server
to facilitate secure communication over an untrusted network. Referring
now to FIG. 5, method 500 begins by receiving a message. In more detail,
the received message may be in the form of an encrypted message and a
message specific identifier from a sending device. The message specific
identifier is associated with one or more attributes associated with the
message and the sending device

[0044] At step 510, the user is prompted for login information. In one
embodiment, the secure receiving module 240 prompts the recipient user to
enter login information in the form of a user ID and password (such as a
PIN). The user ID and password may be based in part at least on
biometric, numeric, alphabetic, alphanumeric or a combination of such
characteristics. Once it is verified that the user login information is
valid (e.g., the recipient device is in the possession and control of the
appropriate user of the devices), the module 240 accesses the message and
the message specific identifier at step 515.

[0045] At step 520, module 240 generates a decryption key request (DKR).
In an embodiment, the DKR is based upon the message specific identifier
and a second device attribute (e.g., the device specific hardware address
for the recipient device, such as the recipient device's media access
control (MAC) address). After sending the DKR to the server and after the
server has validated the DKR, module 240 receives a decryption key from
the server based on the message specific identifier and a stored random
character set. At step 535, the module decrypted the encrypted message
using the decryption key constructed by the server.

[0046] After decryption, the module 240 destroys the decryption key at
step 540 as a measure of security. In other embodiments, the recipient
device may have enterprise or user defined preferences where the
decryption key may be saved permanently in memory storage 215 (e.g., as
part of device specific data 245), saved only temporarily in memory
storage 215 for a specific period of time, or saved transiently in
volatile memory 220 without placement into longer term non-volatile
memory storage.

[0047] While FIGS. 4 and 5 provide steps for operating devices in
embodiments from the device perspective when securely communicating a
message using a message specific identifier, FIG. 6 illustrates exemplary
steps from a method involved in facilitating secure communication from a
server perspective. Referring now to FIG. 6, the overall method of
operation 600 involves two main operations - encryption key request
serving and decryption key request serving. Method 600 begins at step 605
where the server receives a key request and step 610 determines the type
of key request. The key request is based upon a message specific
identifier associated with a plurality of attributes associated with the
message and the sending device.

[0048] If the key request is an encryption key request (EKR), the request
is first typically validated in step 615. For example, in one embodiment,
the server validates the EKR by validating the sending device's MAC
address, user ID and password. If the request is not valid, then
operation moves back to step 605 where the server remains ready for the
next key request. However, if the request is valid, operation moves to
step 620 where the EKR and the message specific identifier are parsed
into an intermediate argument. In one embodiment, the intermediate
argument is created by transforming the message specific identifier into
a functional logical argument.

[0049] In step 625, the intermediate argument is used as an entry point
into a random character set. Server 110 periodically generates and stores
random character sets, each of which may be referenced by a random
character set identifier. Thus, step 625 operates to enter the current
random character set using the intermediate argument as the entry point
into the set. Additionally, the intermediate argument is used to identify
one of a plurality of server resident encryption key construction
methods, such as AES, DES or other common encryption methods, algorithms
or paradigms known to one skilled in the art.

[0050] At step 630, the method constructs an encryption key from the
current random character set and the entry point of the current random
character set and the specified encryption key construction paradigm
associated with the intermediate argument. In one embodiment, this
encryption key generation is accomplished by the secure communication
management module 325 where the key request reception and validation may
be performed by the request handling module 330. Those skilled in the art
will appreciate that such modules may be implemented together or in
distinct modules or hardware that operates in accordance with the steps
described in FIG. 6 herein. Additionally, other embodiments may implement
modules 325 and 330 as a lower level BIOS-type of firmware within the
server 110. As such, server 110 may be deployed in many types of general
purpose computing platforms or network communication capable appliances
depending upon the anticipated performance requirements of the secure
communication system (e.g., number of users, variety of devices, period
of generating random character sets, anticipated frequency of secure
communication messaging, complexity of the desired encryption/decryption
methods, etc.).

[0051] At step 635, the method stores a data structure associated with the
message specific identifier, a random character set identifier associated
with the current random character set, an identifier of the relevant
encryption key construction paradigm and associated data related to the
generated encryption key (e.g., addressee and recipient information).
Optionally, the encryption key itself may be stored in the data structure
depending upon the implementation and the desire for other security
checks when serving decryption requests (see, e.g., steps 670, 675). In
the embodiment illustrated in FIG. 3, the stored data structure appears
as server created data structure 335. At step 640, the method transmits
the encryption key generated and constructed by the server based upon the
message specific identifier to the requesting device before returning to
step 605 for the next key request.

[0052] Referring back to step 610, if the key request is a decryption key
request (DKR), then the method proceeds to step 645 where the DKR is
validated before moving on to step 650. In one embodiment, this is
accomplished with the DKR conveying a hash of the incoming encrypted
message's message specific identifier, the receiving device's MAC
address, and the receiving device's user ID and password (e.g., PIN)
login information. With this information, the exemplary server is able to
ensure that only a recognized device under the control of a recognized
user is able to initiate a valid decryption key request.

[0053] After initial validation by the server, the method accesses the
message specific identifier from the DKR to locate a random character set
identifier at step 650. At step 655, the method parses an intermediate
argument from the message specific identifier received from the
requesting device. In an embodiment, the intermediate argument is a
functional logic argument.

[0054] At step 660, the intermediate argument is used to enter the stored
random character set associated with the random character set identifier
located in step 650. In the embodiment of FIG. 3, the secure
communication management module 325 employs the intermediate argument to
enter the referenced one of the stored random character sets at the
position it determines using the intermediate argument as the entry point
to the set. In one embodiment, an encryption key construction paradigm is
identified in response to a message specific identifier originated
intermediate argument. In another embodiment, the encryption key may be
retrieved from memory. At step 665, the method constructs a decryption
key from the referenced random character set and the identified
encryption key paradigm. If the key was previously stored within the
relevant recorded data structure associated with the message specific
identifier, step 670 may allow for an additional level of validation of
the constructed key against the stored key as an additional layer of
security at step 675. Otherwise, the method concludes by transmitting the
constructed decryption key by the server to the requesting device in step
680 before returning operation to step 605 and awaiting the next key
request.

[0055] As generally explained above, the methods exemplified in FIGS. 4-6
may operate in an environment that uses devices that securely communicate
with each other with use of a server. FIG. 7 is a message flow diagram
illustrating exemplary devices 105a, 105b and an exemplary Communications
Encryption Server (CES) 110 in an alternative embodiment that implements
the interfaces to the server with BIOS level modules (e.g., module 735,
740). One skilled in the art will also appreciate that reference to MUI
in FIG. 7 indicates the type of message specific identifier assembled by
device 105a and used by CES 110 for encryption and decryption is a
message unique identifier (MUI) comprising a hash of attributes (such as
the sending device's MAC address, date/time stamp, sender address of the
message, recipient address of the message, device microprocessor ID, user
ID, PIN or other common message attributes). As generally explained with
reference to FIG. 4, device 105a may assemble the MUI as a type of
message specific identifier organic to the message and associated with
message attributes and the sending device (i.e., device 105a). As such,
the MUI is an information-based indicator that is unique with respect to
the message and the sending device, and with which CES 110 may create an
encryption key (e.g., using a BIOS resident program 725 and one of a
plurality of encryption key construction methods implemented within
program 725) for use in encrypting the message. Furthermore, the MUI may
be sent with the message, as indicated in FIG. 7, after the BIOS
interface sending module 735 encrypts the message, destroys the key, and
returns the message to the device message client operating as or part of
a messaging application on device 105a for subsequent transmission to the
recipient device 105b.

[0056] In the embodiment illustrated in FIG. 7, the core of the
communication encryption BIOS program 725 is a set of executable
instructions generally implemented with a set of inputs and outputs. For
example, in one embodiment, the BIOS core input may be the MUI based
intermediate argument used for encryption and decryption. And BIOS core
outputs may include random character set selection, random character set
entry point, and an identifier of the relevant BIOS resident encryption
key construction paradigm. As such, with the MUI, the BIOS output
functions set forth above may be readily and repeatedly reproduced from
the MUI based intermediate argument and do not need to be stored in
memory. In some embodiments, such information may be stored for ease of
retrieval. However, in other embodiments, such information is not stored
to help better ensure security against hacking of the stored data
structures.

[0057] Upon receipt by the device message client operating on device 105b,
the BIOS interface receiving module 740 may retrieve the message and,
along with one or more attributes related to the receiving device (e.g.,
local device MAC, local device microprocessor ID, recipient user ID,
recipient PIN), generate a decryption key request for CES 110 in line
with the general steps described in FIG. 5. Thus, CES 110 as shown in
FIG. 7 operates as generally explained with reference to FIG. 6 to
facilitate secure communication between devices 105a and 105b, each of
which being implemented with BIOS implemented sending and receiving
modules shown in FIG. 7.

[0058] While the above described embodiments explain the principles of the
present invention in terms of two devices and a facilitating server in
communication with each of the devices, embodiments of the invention may
also be applied to other types of devices and at communication within
other types of systems.

[0059] At least some portions of exemplary embodiments of the systems,
apparatus and methods outlined above may used in association with
portions of other exemplary embodiments. Moreover, at least some of the
exemplary embodiments disclosed herein may be used independently from one
another and/or in combination with one another and may have applications
to devices and methods not disclosed herein.

[0060] It will be apparent to those skilled in the art that various
modifications and variations can be made to the structures and
methodologies described herein. Thus, it should be understood that the
invention is not limited to the subject matter discussed in the
description. Rather, the present invention is intended to cover
modifications and variations.

Patent applications by Steven J. Drucker, Atlanta, GA US

Patent applications in class Authentication of an entity and a message

Patent applications in all subclasses Authentication of an entity and a message