The present invention relates to various methods, software programs, and systems for electronic information security. More particularly, these various methods, software programs, and systems may serve to protect information security by providing an integrated system that helps ensure confidentiality, integrity, accountability, and ease of use. Certain embodiments of the present invention relate to methods, software programs, and systems for electronic information security utilizing a file container for storing: (a) a data file, which data file is encrypted with a one-time random encryption key; (b) the one-time random encryption key, which one-time random encryption key is encrypted with a public key portion of a public key/private key pair associated with an owner of the file container; (c) an audit trail log of the history of the file container, which audit trail log is encrypted with the one-time random encryption key with which the data file is encrypted; (d) a digital signature based upon a hash of the combined data file and the audit trail log, which hash is encrypted with a private key portion of a public key/private key associated with a writer/creator of the file container; and (e) a profile associated with the file container. Additional embodiments of the present invention relate to methods, software programs, and systems for electronic information security utilizing a fully integrated system for user authentication, virus scanning, time/date certification, encryption/decryption, digital signatures, stored document protection, transmitted document protection, and delivery verification.
|
8. A method for providing autonomous file level security to protect one or more digital files to be accessed by a user, comprising steps of:
creating a digital processor-readable strongbox container digital file to be stored on a digital storage medium, wherein the strongbox container can store one or more secure digital files;
creating an audit trail log to record each user interaction with the strongbox container and its contents, wherein each log entry is digitally signed by the user, and wherein the audit trail log is stored in the strongbox container; and
creating authentication information defining the user's privileges for interacting with the one or more secure digital files and the audit trail log, wherein the authentication information is stored in the strongbox container;
wherein the user's ability to interact with the strongbox container and its contents is based on the authentication information independent of the digital storage medium, digital processor or any operating system on the digital storage medium or digital processor.
2. A digital processor-readable strongbox container digital file disposed on a digital storage medium, the file including instructions executable by a processor for providing autonomous file level security to protect one or more digital files to be stored therein and to be accessed by a user the file comprising:
instructions for allowing access to one or more secure digital files in the strongbox container;
an audit trail log comprising one or more entries, wherein each user interaction with the strongbox container and its contents is recorded and digitally signed by the user; and
authentication information defining the user's privileges for interacting with the one or more secure digital files and the audit trail log,
wherein said recorded user interactions include one or more of: each attempt by the user to access and/or manipulate the strongbox and/or its content; each manipulation of the strongbox and/or its content; and manipulation of the authentication information for modifying user permissions and/or privileges;
wherein the user's ability to interact with the secure strongbox container digital file and its contents is based on the authentication information independent of the digital processor or operating system upon which they reside.
7. A method for providing autonomous file level security to protect one or more digital files to be accessed by a user, comprising steps of:
creating a digital processor-readable strongbox container digital file to be stored on a digital storage medium, wherein the strongbox container can store one or more secure digital files;
creating an audit trail log to record each user interaction with the strongbox container and its contents, wherein each log entry is digitally signed by the user, and wherein the audit trail log is stored in the strongbox container; and
creating authentication information defining the user's privileges for interacting with the one or more secure digital files and the audit trail log, wherein the authentication information is stored in the strongbox container;
wherein said recorded user interactions include one or more of: each attempt by the user to access and/or manipulate the strongbox and/or its content; each manipulation of the strongbox and/or its content; and manipulation of the authentication information for modifying user permissions and/or privileges; and
wherein the user's ability to interact with the strongbox container and its contents is based on the authentication information independent of the digital storage medium, digital processor or any operating system on the digital storage medium or digital processor.
1. A digital processor-readable strongbox container digital file disposed on a digital storage medium, the file including instructions executable by a processor for providing autonomous file level security to protect one or more digital files to be stored therein and to be accessed by a user, the file comprising:
instructions for allowing access to one or more secure digital files in the strongbox container, each of the digital files being encrypted and digitally signed;
an audit trail log comprising one or more entries, wherein each user interaction with the strongbox is recorded and digitally signed by each user;
authentication information defining for each user who has permission to access the strongbox, each user's privileges for accessing the strongbox, the one or more protected files, the audit trail log, and each user's authentication privileges;
wherein said recorded user interactions include one or more of: each attempt by the user to access and/or manipulate the strongbox and/or its content: each manipulation of the strongbox and/or its content; and manipulation of the authentication information for modifying user permissions and/or privileges;
and
wherein each user's ability to interact with the container is based on the authentication and encryption information independent of the digital processor or operating system upon which it resides.
3. The container of
5. The container of
6. The container of
|
|||||||||||||||||||||||||||
This application claims the benefit under 35 U.S.C. 119(e) of U.S. Provisional Application Ser. No. 60/353,635, filed Jan. 31, 2002.
The present invention relates to various methods, software programs, and systems for electronic information security. More particularly, certain embodiments of the present invention relate to methods, software programs, and systems for electronic information security utilizing a file container for storing: (a) a data file, which data file is encrypted with a one-time random encryption key; (b) the one-time random encryption key, which one-time random encryption key is encrypted with a public key portion of a public key/private key pair associated with an owner of the file container; (c) an audit trail log of the history of the file container, which audit trail log is encrypted with the one-time random encryption key with which the data file is encrypted; (d) a digital signature based upon a hash of the combined data file and the audit trail log, which hash is encrypted with a private key portion of a public key/private key associated with a writer/creator of the file container; and (e) a profile associated with the file container.
For the purposes of the present application the term “entity” is intended to refer to any person, organization, or group.
Further, for the purposes of the present application the term “file container” is intended to refer to a mechanism for storing information, including the information in one or more data files.
Further still, for the purposes of the present application the term “file container creation operation” is intended to refer to generating a new instance of a file container.
Further still, for the purposes of the present application the term “file container writing operation” is intended to refer to modifying information stored in or associated with an existing file container. Such a file container writing operation may include “opening” the file container to write one or more various elements (such as distinct computer files) thereto and/or “opening” one or more of the various elements themselves to write thereto.
Further still, for the purposes of the present application the term “file container reading operation” is intended to refer to accessing information stored in or associated with an existing file container (without modifying the information). Such a file container reading operation may include “opening” the file container to read one or more various elements (such as distinct computer files) therein and/or “opening” one or more of the various elements themselves to read.
Further still, for the purposes of the present application the term “writer/creator” is intended to refer to the entity who most recently performed either a file container creation operation or a file container writing operation upon a specific file container.
Further still, for the purposes of the present application the term “owner of the file container” is intended to refer to the entity for whom the file container is created or written. The “owner” may or may not be the entity who has created or last written to the file container.
Further still, for the purposes of the present application the term “third party” is intended to refer to an entity that is neither the writer/creator of a specific file container nor the owner of the specific file container.
Further still, for the purposes of the present application the term “ftp operation” is intended to refer, but not be limited to, transmitting data using a file transfer protocol.
Further still, for the purposes of the present application the term “web browsing operation” is intended to refer, but not be limited to, transmitting data using a hypertext transfer protocol.
Further still, for the purposes of the present application the term “emailing operation” is intended to refer, but not be limited to, transmitting data using an email protocol.
Further still, for the purposes of the present application the term “encryption” is intended to refer to the process of converting some information (the “message”), usually represented as a string of characters (e.g., numbers, letters, symbols), into a different set of characters. The intention of encryption is typically to disguise the original message (the “plain text”) so that in its encrypted form (the “cipher text”) it is no longer recognizable and/or comprehensible.
Further still, for the purposes of the present application the term “decryption” is intended to refer to the reverse process of encryption. That is, decryption converts an encrypted “message” (the “cipher text”) back into its original form (the “plain text”).
Further still, for the purposes of the present application the term “computer virus” (or “virus”) is intended to refer to a computer program that was designed to and/or actually operates in a generally malicious, counterproductive, and/or destructive manner.
Further still, for the purposes of the present application the term “virus scanning operation” (or “virus scanning”) is intended to refer to detecting and/or eliminating a computer virus.
Further still, for the purposes of the present application the term “time/date stamp” is intended to refer to a mechanism for identifying the time and/or date of an event (such as a file container creation operation, a file container writing operation, or a file container reading operation, for example).
Further still, for each term which is identified herein as “intended to include, but not be limited to” certain definition(s), when such term is used in the claims the term is to be construed more specifically as “intended to include at least one of the definition(s)”.
A. Encryption
The basis of conventional encryption typically involves the use of one or more “keys”. If a party knows the encryption key and the process used to encrypt the message, the message can be encrypted. If a party knows the decryption key and the process used to decrypt the message, the party can decrypt the message. Typically, within any given system, these processes remain static and only the keys change. For example, consider the famous “2001 Space Odyssey Code”: The computer's name is HAL, the HAL 9000. Many people regard that name as being an encrypted name. Why? Add one letter to each of the letters in the name “HAL”. H+1=I, A+1=B, and L+1=M. “IBM”. In this case the process of decryption is to add a key to each letter. The key used is the number 1. Similarly the process of encryption (to convert from “IBM” into “HAL”) would be to subtract the key from each letter. Here again, the key used is the number 1.
The above-described example of encryption is illustrated in
On the other hand, a different conventional process known as “asymmetric encryption” uses two keys. Under this system one key is used to encrypt the message and the other key, a different key, must be used to decrypt it. For this system to work, the two keys must, of course, be related; however, if the asymmetric encryption is to be effective the relationship between the two different keys cannot be obvious (i.e., knowing one key does not enable someone to automatically know the other key).
An important feature of such conventional asymmetric encryption is that either key can be used as the encryption key. Thus, if the initial “plain text” message is encrypted using Key #1, the encrypted text (“cipher text”) can only be decrypted (converted back into “plain text”) using Key#2. But if the plain text is encrypted using Key #2, the resulting cipher text can only be decrypted using Key #1. This relationship is illustrated in
In addition, it is noted that conventional public key/private key technology is based upon asymmetric encryption. The concept is that each participant in the system has two keys. One key, the “private key”, is kept private, known to, or accessible by, only the individual key owner (i.e., the entity associated with the key). The other key, the “public key”, is considered public and is published to the world. The two keys work symmetrically. That is: (a) if a message is encrypted with an entity's public key, the message can only be decrypted with that entity's private key; and (b) if a message is encrypted with an entity's private key, the message can only be decrypted with that entity's public key.
When one is working with a conventional encryption mechanism there are certain important factors to note (because not all encryption is the same and not all public key/private key systems are the same). Some of the relevant issues are:
B. Digital Signatures
Conventional digital signatures serve two important purposes: (a) non-repudiation (i.e., the “signer” of an electronic document cannot deny having signed it); and (b) tamper-proofing (i.e., the contents of the electronic document cannot be changed without invalidating the digital signature).
Conventional digital signature technology is based upon two component technologies: (a) the public key/private key concept; and (b) a hash function (a hash function is a complex mathematical function, or formula, that uses the numeric representation of a document's content [e.g., text] to produce a specific number, the “hash value” of a document; conventional hash functions have been formulated in such a manner as to render it relatively easy to produce a hash value of a text, but almost impossible to produce a text that will yield a predetermined hash value).
Unlike handwritten, or even “digitized signatures” (i.e., digital images of handwritten signatures), each digital signature is different for each electronic document signed. In one example, a conventional mechanism used to create a digital signature for a specific document involves producing the hash value for the document and then encrypting the hash value with the signer's private key. This process is illustrated in
A signature, however, is essentially without value unless it can be “verified”. Conventional digital signature verification confirms not only who signed the document but also that the document has not been changed in any way. The process of digital signature verification works as shown in
More particularly, to verify the signature using a conventional process, the verifier:
C. Authentication
Finally, it is noted that authentication is the means whereby system users are identified. In other words, authentication is verification of identity. Conventionally, there are three distinct types of authentication that correspond to the three distinct situations when authentication is required:
Among those benefits and improvements that have been disclosed, other objects and advantages of this invention will become apparent from the following description taken in conjunction with the accompanying figures. The figures constitute a part of this specification and include illustrative embodiments of the present invention and illustrate various objects and features thereof.
As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely illustrative of the invention that may be embodied in various forms. In addition, each of the examples given in connection with the various embodiments of the invention are intended to be illustrative, and not restrictive. Further, the figures are not necessarily to scale, some features may be exaggerated to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present invention.
In one embodiment an electronic information security mechanism is provided, comprising: a file container for storing: (a) a data file, which data file is encrypted with a one-time random encryption key; (b) the one-time random encryption key, which one-time random encryption key is encrypted with a public key portion of a public key/private key pair associated with an owner of the file container; (c) an audit trail log of the history of the file container, which audit trail log is encrypted with the one-time random encryption key with which the data file is encrypted; (d) a digital signature based upon a hash of the combined data file and the audit trail log, which hash is encrypted with a private key portion of a public key/private key associated with a writer/creator of the file container; and (e) a profile associated with the file container.
In one example the digital signature may be encrypted with the one-time random encryption key with which the data file is encrypted.
In another example the profile associated with the file container may be encrypted with one of: (a) the private key portion of the public key/private key pair associated with the writer/creator of the file container; and (b) the one-time random encryption key with which the data file is encrypted.
In another example the file container may store a public key portion of the public key/private key pair associated with the writer/creator of the file container.
In another example the public key portion of the public key/private key pair associated with the writer/creator of the file container may be encrypted with the one-time random encryption key with which the data file is encrypted.
In another example the owner of the file container and the writer/creator of the file container may be distinct entities and each of the public key/private key pair associated with the owner of the file container and the public key/private key pair associated with the writer/creator of the file container may be unique.
In another example the owner of the file container and the writer/creator of the file container may be the same entity and the public key/private key pair associated with the owner of the file container and the public key/private key pair associated with the writer/creator of the file container may be identical.
In another example the file container may be an electronic file container adapted for processing by a computer.
In another example the processing may include at least one of the following operations: (a) a file container creation operation; (b) a file container reading operation; and (c) a file container writing operation.
In another embodiment an electronic information security mechanism is provided, comprising: means for carrying out at least one of a file container creation operation, a file container reading operation, and a file container writing operation on a file container storing: (a) a data file, which data file is encrypted with a one-time random encryption key; (b) the one-time random encryption key, which one-time random encryption key is encrypted with a public key portion of a public key/private key pair associated with an owner of the file container; (c) an audit trail log of the history of the file container, which audit trail log is encrypted with the one-time random encryption key with which the data file is encrypted; (d) a digital signature based upon a hash of the combined data file and the audit trail log, which hash is encrypted with a private key portion of a public key/private key associated with a writer/creator of the file container; and (e) a profile associated with the file container.
In one example the digital signature may be encrypted with the one-time random encryption key with which the data file is encrypted.
In another example the profile associated with the file container may be encrypted with one of: (a) the private key portion of the public key/private key pair associated with the writer/creator of the file container; and (b) the one-time random encryption key with which the data file is encrypted.
In another example the file container may store a public key portion of the public key/private key pair associated with the writer/creator of the file container.
In another example the public key portion of the public key/private key pair associated with the writer/creator of the file container may be encrypted with the one-time random encryption key with which the data file is encrypted.
In another example the file container may be an electronic file container adapted for processing by a computer and the means for carrying out at least one of the file container creation operation, the file container reading operation, and the file container writing operation on the file container may include computer software.
In another example the owner of the file container and the writer/creator of the file container may be distinct entities and each of the public key/private key pair associated with the owner of the file container and the public key/private key pair associated with the writer/creator of the file container may be unique.
In another example the owner of the file container and the writer/creator of the file container may be the same entity and the public key/private key pair associated with the owner of the file container and the public key/private key pair associated with the writer/creator of the file container may be identical.
In another example the means for carrying out at least one of the file container creation operation, the file container reading operation, and the file container writing operation on the file container may include means for encrypting at least one of: (a) the data file with the one-time random encryption key; (b) the one-time random encryption key with the public key portion of the public key/private key pair associated with the owner of the file container; (c) the audit trail log of the history of the file container with the one-time random encryption key with which the data file is encrypted; (d) the digital signature with the one-time random encryption key with which the data file is encrypted; (e) the profile associated with the file container with one of: (i) the private key portion of the public key/private key pair associated with the writer/creator of the file container; and (ii) the one-time random encryption key with which the data file is encrypted; and (f) the public key portion of the public key/private key pair associated with the writer/creator of the file container with the one-time random encryption key with which the data file is encrypted.
In another example the means for carrying out at least one of the file container creation operation, the file container reading operation, and the file container writing operation on the file container may include virus scanning means for virus scanning at least one of: (a) the data file before encryption; (b) the one-time random encryption key before encryption; (c) the audit trail log of the history of the file container before encryption; (d) the digital signature before encryption; (e) the profile associated with the file container before encryption; and (f) the public key portion of the public key/private key pair associated with the writer/creator of the file container before encryption.
In another example the means for carrying out at least one of the file container creation operation, the file container reading operation, and the file container writing operation on the file container may include means for decrypting at least one of: (a) the encrypted data file; (b) the encrypted one-time random encryption key; (c) the encrypted audit trail log of the history of the file container; (d) the encrypted digital signature; (e) the encrypted profile associated with the file container; and (f) the encrypted public key portion of the public key/private key pair associated with the writer/creator of the file container.
In another example the means for carrying out at least one of the file container creation operation, the file container reading operation, and the file container writing operation on the file container may include virus scanning means for virus scanning at least one of: (a) the data file after decryption; (b) the one-time random encryption key after decryption; (c) the audit trail log of the history of the file container after decryption; (d) the digital signature after decryption; (e) the profile associated with the file container after decryption; and (f) the public key portion of the public key/private key pair associated with the writer/creator of the file container after decryption.
In another example the invention may comprise means for adding a time/date stamp to the file container.
In another example the time/date stamp may correspond to a most recent operation selected from the group of: (a) a file container creation operation; (b) a file container writing operation; (c) a file reading operation; and (d) a virus scanning operation.
In another example the time/date stamp may be digitally signed.
In another example the time/date stamp may be digitally signed by a third party.
In another embodiment an electronic information security mechanism for use with a computer running at least a first application and a second application is provided, comprising: first data interface means for exchanging data with the first application; second data interface means for exchanging data with the second application; and means for carrying out at least one of a file container creation operation, a file container reading operation, and a file container writing operation on a file container storing: (a) a data file, which data file is encrypted with a one-time random encryption key; (b) the one-time random encryption key, which one-time random encryption key is encrypted with a public key portion of a public key/private key pair associated with an owner of the file container; (c) an audit trail log of the history of the file container, which audit trail log is encrypted with the one-time random encryption key with which the data file is encrypted; (d) a digital signature based upon a hash of the combined data file and the audit trail log, which hash is encrypted with a private key portion of a public key/private key associated with a writer/creator of the file container; and (e) a profile associated with the file container; wherein the means for carrying out at least one of the file container creation operation, the file container reading operation, and the file container writing operation on the file container includes means for providing the first application access to data in the data file through the first data interface means for exchanging data and means for providing the second application access to data in the data file through the second data interface means for exchanging data.
In one example the digital signature may be encrypted with the one-time random encryption key with which the data file is encrypted.
In another example the profile associated with the file container may be encrypted with one of: (a) the private key portion of the public key/private key pair associated with the writer/creator of the file container; and (b) the one-time random encryption key with which the data file is encrypted.
In another example the file container may store a public key portion of the public key/private key pair associated with the writer/creator of the file container.
In another example the public key portion of the public key/private key pair associated with the writer/creator of the file container may be encrypted with the one-time random encryption key with which the data file is encrypted.
In another example the file container may be an electronic file container adapted for processing by a computer and the means for carrying out at least one of the file container creation operation, the file container reading operation, and the file container writing operation on the file container may include computer software.
In another example the owner of the file container and the writer/creator of the file container may be distinct entities and each of the public key/private key pair associated with the owner of the file container and the public key/private key pair associated with the writer/creator of the file container may be unique.
In another example the owner of the file container and the writer/creator of the file container may be the same entity and the public key/private key pair associated with the owner of the file container and the public key/private key pair associated with the writer/creator of the file container may be identical.
In another example the means for carrying out at least one of the file container creation operation, the file container reading operation, and the file container writing operation on the file container may include means for encrypting at least one of: (a) the data file with the one-time random encryption key; (b) the one-time random encryption key with the public key portion of the public key/private key pair associated with the owner of the file container; (c) the audit trail log of the history of the file container with the one-time random encryption key with which the data file is encrypted; (d) the digital signature with the one-time random encryption key with which the data file is encrypted; (e) the profile associated with the file container with at least one of: (i) the private key portion of the public key/private key pair associated with the writer/creator of the file container; and (ii) the one-time random encryption key with which the data file is encrypted; and (f) the public key portion of the public key/private key pair associated with the writer/creator of the file container with the one-time random encryption key with which the data file is encrypted.
In another example the means for carrying out at least one of the file container creation operation, the file container reading operation, and the file container writing operation on the file container may include virus scanning means for virus scanning at least one of: (a) the data file before encryption; (b) the one-time random encryption key before encryption; (c) the audit trail log of the history of the file container before encryption; (d) the digital signature before encryption; (e) the profile associated with the file container before encryption; and (f) the public key portion of the public key/private key pair associated with the writer/creator of the file container before encryption.
In another example the means for carrying out at least one of the file container creation operation, the file container reading operation, and the file container writing operation on the file container may include means for decrypting at least one of: (a) the encrypted data file; (b) the encrypted one-time random encryption key; (c) the encrypted audit trail log of the history of the file container; (d) the encrypted digital signature; (e) the encrypted profile associated with the file container; and (f) the encrypted public key portion of the public key/private key pair associated with the writer/creator of the file container.
In another example the means for carrying out at least one of the file container creation operation, the file container reading operation, and the file container writing operation on the file container may include virus scanning means for virus scanning at least one of: (a) the data file after decryption; (b) the one-time random encryption key after decryption; (c) the audit trail log of the history of the file container after decryption; (d) the digital signature after decryption; (e) the profile associated with the file container after decryption; and (f) the public key portion of the public key/private key pair associated with the writer/creator of the file container after decryption.
In another example the invention may further comprise means for adding a time/date stamp to the file container.
In another example the time/date stamp may correspond to a most recent operation selected from the group of: (a) a file container creation operation; (b) a file container writing operation; (c) a file reading operation; and (d) a virus scanning operation.
In another example the time/date stamp may be digitally signed.
In another example the time/date stamp may be digitally signed by a third party.
In another example, the invention may further comprise authentication means for authenticating a user of the first application and a user of the second application.
In another embodiment an electronic information security mechanism for use with a first computer and a second computer is provided, comprising: first processing means associated with the first computer for carrying out at least one of a file container creation operation, a file container reading operation, and a file container writing operation on a file container storing: (a) a data file, which data file is encrypted with a one-time random encryption key; (b) the one-time random encryption key, which one-time random encryption key is encrypted with a public key portion of a public key/private key pair associated with an owner of the file container processed by the first processing means; (c) an audit trail log of the history of the file container, which audit trail log is encrypted with the one-time random encryption key with which the data file processed by the first processing means is encrypted; (d) a digital signature based upon a hash of the combined data file processed by the first processing means and the audit trail log processed by the first processing means, which hash is encrypted with the private key portion of a public key/private key pair associated with a writer/creator of the file container processed by the first processing means; and (e) a profile associated with the file container processed by the first processing means; second processing means associated with the second computer for carrying out at least one of a file container creation operation, a file container reading operation, and a file container writing operation on a file container storing: (a) a data file, which data file is encrypted with a one-time random encryption key; (b) the one-time random encryption key, which one-time random encryption key is encrypted with a public key portion of a public key/private key pair associated with an owner of the file container processed by the second processing means; (c) an audit trail log of the history of the file container, which audit trail log is encrypted with the one-time random encryption key with which the data file processed by the second processing means is encrypted; (d) a digital signature based upon a hash of the combined data file processed by the second processing means and the audit trail log processed by the second processing means, which hash is encrypted with the private key portion of a public key/private key pair associated with a writer/creator of the file container processed by the second processing means; and (e) a profile associated with the file container processed by the second processing means; first exchange means associated with the first computer for sending a file container processed by the first processing means to the second computer and for receiving a file container processed by the second processing means from the second computer; and second exchange means associated with the second computer for sending a file container processed by the second processing means to the first computer and for receiving a file container processed by the first processing means from the first computer.
In one example: a) the file container processed by the first processing means may be an electronic file container adapted for processing by a computer and the first processing means may include computer software; and b) the file container processed by the second processing means may be an electronic file container adapted for processing by a computer and the second processing means may include computer software.
In another example the owner of the file container processed by the first processing means and the writer/creator of the file container processed by the first processing means may be distinct entities and each of the public key/private key pair associated with the owner of the file container processed by the first processing means and the public key/private key pair associated with the writer/creator of the file container processed by the first processing means may be unique.
In another example the owner of the file container processed by the second processing means and the writer/creator of the file container processed by the second processing means may be distinct entities and each of the public key/private key pair associated with the owner of the file container processed by the second processing means and the public key portion of the public key/private key pair associated with the writer/creator of the file container processed by the second processing means may be unique.
In another example the owner of the file container processed by the first processing means and the writer/creator of the file container processed by the first processing means may be the same entity and the public key/private key pair associated with the owner of the file container processed by the first processing means and the public key/private key pair associated with the writer/creator of the file container processed by the first processing means may be identical.
In another example the owner of the file container processed by the second processing means and the writer/creator of the file container processed by the second processing means may be the same entity and the public key/private key pair associated with the owner of the file container processed by the second processing means and the public key/private key pair associated with the writer/creator of the file container processed by the second processing means may be identical.
In another example: (i) the file container processed by the first processing means may include a public key portion of the public key/private key pair associated with the writer/creator of the file container; and (ii) the file container processed by the second processing means may include a public key portion of the public key/private key pair associated with the writer/creator of the file container.
In another example: (i) the first processing means may include first encryption means for encrypting at least one element of the file container processed by the first processing means as follows: (a) the data file with the one-time random encryption key; (b) the one-time random encryption key with the public key portion of the public key/private key pair associated with the owner of the file container; (c) the audit trail log of the history of the file container with the one-time random encryption key with which the data file is encrypted; (d) the digital signature with the one-time random encryption key with which the data file is encrypted; (e) the profile associated with the file container with one of: (i) the private key portion of the public key/private key pair associated with the writer/creator of the file container; and (ii) the one-time random encryption key with which the data file is encrypted; and (f) the public key portion of the public key/private key pair associated with the writer/creator of the file container encrypted with the one-time random encryption key with which the data file is encrypted; and (ii) the second processing means may include second encryption means for encrypting at least one element of the file container processed by the second processing means as follows: (a) the data file with the one-time random encryption key; (b) the one-time random encryption key with the public key portion of the public key/private key pair associated with the owner of the file container; (c) the audit trail log of the history of the file container with the one-time random encryption key with which the data file is encrypted; (d) the digital signature with the one-time random encryption key with which the data file is encrypted; (e) the profile associated with the file container with one of: (i) the private key portion of the public key/private key pair associated with the writer/creator of the file container; and (ii) the one-time random encryption key with which the data file is encrypted; and (f) the public key portion of the public key/private key pair associated with the writer/creator of the file container encrypted with the one-time random encryption key with which the data file is encrypted.
In another example: (i) the first processing means may include first virus scanning means for virus scanning at least one element of the file container processed by the first processing means as follows: (a) the data file before encryption; (b) the one-time random encryption key before encryption; (c) the audit trail log of the history of the file container before encryption; (d) the digital signature before encryption; (e) the profile associated with the file container before encryption; and (f) the public key portion of the public key/private key pair associated with the writer/creator of the file container before encryption; and (ii) the second processing means may include second virus scanning means for virus scanning at least one element of the file container processed by the second processing means as follows: (a) the data file before encryption; (b) the one-time random encryption key before encryption; (c) the audit trail log of the history of the file container before encryption; (d) the digital signature before encryption; (e) the profile associated with the file container before encryption; and (f) the public key portion of the public key/private key pair associated with the writer/creator of the file container before encryption.
In another example: (i) the first processing means may include first decryption means for decrypting at least one of the following elements of the file container processed by the first processing means: (a) the encrypted data file; (b) the encrypted one-time random encryption key; (c) the encrypted audit trail log of the history of the file container; (d) the encrypted digital signature; (e) the encrypted profile associated with the file container; and (f) the encrypted public key portion of the public key/private key pair associated with the writer/creator of the file container; and (ii) the second processing means may include second decryption means for decrypting at least one of the following elements of the file container processed by the second processing means: (a) the encrypted data file; (b) the encrypted one-time random encryption key; (c) the encrypted audit trail log of the history of the file container; (d) the encrypted digital signature; (e) the encrypted profile associated with the file container and (f) the encrypted public key portion of the public key/private key pair associated with the writer/creator of the file container.
In another example: (i) the first processing means may include first virus scanning means for virus scanning at least one element of the file container processed by the first processing means as follows: (a) the data file after decryption; (b) the one-time random encryption key after decryption; (c) the audit trail log of the history of the file container after decryption; (d) the digital signature after decryption; (e) the profile associated with the file container after decryption; and (f) the public key portion of the public key/private key pair associated with the writer/creator of the file container after decryption; and (ii) the second processing means may include second virus scanning means for virus scanning at least one element of the file container processed by the second processing means as follows: (a) the data file after decryption; (b) the one-time random encryption key after decryption; (c) the audit trail log of the history of the file container after decryption; (d) the digital signature after decryption; (e) the profile associated with the file container after decryption; and (f) the public key portion of the public key/private key pair associated with the writer/creator of the file container after decryption.
In another example the invention may further comprise means for adding a time/date stamp to at least one of: (a) the file container processed by the first processing means; and (b) the file container processed by the second processing means.
In another example the time/date stamp may correspond to a most recent operation selected from the group of: (a) a file container creation operation; (b) a file container writing operation; (c) a file reading operation; and (d) a virus scanning operation.
In another example the time/date stamp may be digitally signed.
In another example the time/date stamp may be digitally signed by a third party.
In another example the invention may further comprise authentication means for authenticating a user of the first computer.
In another example the invention may further comprise authentication means for authenticating a user of the second computer.
In another example the first computer, the second computer, the first processing means, the second processing means, the first exchange means, and the second exchange means may be used for at least part of a mechanism for carrying out at least one of an ftp operation, a web browsing operation, and an emailing operation.
In another embodiment a security mechanism for disguising a chosen name of an electronic file from a computer operating system is provided, comprising: means for generating an alias name for the electronic file; means for storing the chosen name and the alias name as an associated pair of names; and means for applying the alias name to the electronic file, wherein the computer operating system identifies the electronic file by the alias name.
In one example the means for generating the alias name and the means for applying the alias name may comprise computer software and the means for storing the chosen name and the alias name as the associated pair of names may comprise a look-up table.
In another example at least one of the alias name, the chosen name, the associated pair of names, and the look-up table may be encrypted.
In another example the means for generating the alias name may generate an alias name which is selected from the group including, but not limited to: (a) random alphanumeric characters; (b) pseudo-random alphanumeric characters; (c) a predetermined group of alphanumeric characters; (d) a pseudo-random combination of characters; and (e) a pseudo-random combination of groups of characters.
In another embodiment a security mechanism for disguising an identity of an entity associated with an electronic file from a computer operating system is provided, comprising: means for generating an alias entity associated with the electronic file; means for storing an identification of the entity associated with the electronic file and an identification of the alias entity associated with the electronic file as an associated pair of identities; and means for associating the alias entity with the electronic file, wherein the computer operating system associates the alias entity with the electronic file.
In one example the means for generating the alias entity and the means for associating the alias entity may comprise computer software and the means for storing the identification of the entity and the identification of the alias entity as the associated pair of identities may comprise a look-up table.
In another example at least one of the alias entity, the identity of the entity associated with the electronic file, the associated pair of identities, and the look-up table may be encrypted.
In another example the means for generating the alias entity may generate an alias entity which is selected from the group including, but not limited to: (a) random alphanumeric characters; (b) pseudo-random alphanumeric characters; (c) a predetermined group of alphanumeric characters; (d) a pseudo-random combination of characters; and (e) a pseudo-random combination of groups of characters.
In another embodiment a method for sending information from a sender to a recipient is provided, comprising: assembling a return receipt package including a message portion and a receipt portion, wherein the message portion includes: (a) a message file encrypted with a one-time random encryption key; (b) a message unique ID associated with the message file encrypted with a public key portion of a public key/private key pair associated with the recipient; (c) a sender ID associated with the sender encrypted with the public key portion of the public key/private key pair associated with the recipient; (d) a time/date stamp encrypted with the public key portion of the public key/private key pair associated with the recipient; and (e) a digital signature associated with the sender; and the receipt portion includes: (a) the one-time random encryption key encrypted with a public key portion of the public key/private key pair associated with the sender; and (b) the message unique ID encrypted with the public key portion of the public key/private key pair associated with the sender; sending the return receipt package from the sender to the recipient; storing the message portion after receipt by the recipient; assembling a receipt portion acknowledgement message including: (a) the receipt portion of the return receipt package; (b) a recipient ID associated with the recipient encrypted with the public key portion of the public key/private key pair associated with the sender; (c) a time/date stamp encrypted with the public key portion of the public key/private key pair associated with the sender; and (d) a digital signature associated with the recipient; sending the receipt portion back to the sender; assembling a release including: (a) the one-time random encryption key encrypted with the public key portion of the public key/private key pair associated with the recipient; (b) the message unique ID encrypted with the public key portion of the public key/private key pair associated with the recipient; (c) the digital signature associated with the sender; and (d) a time/date stamp encrypted with the public key portion of the public key/private key pair associated with the recipient; and sending the release from the sender to the recipient.
In one example the digital signature associated with the sender may be encrypted with a public key portion of a public key/private key pair associated with the recipient.
In another example the digital signature associated with the recipient may be encrypted with a public key portion of a public key/private key pair associated with the sender.
In another example the invention may further comprise decrypting the one-time random encryption key contained within the release using the public key portion of the public key/private key pair associated with the recipient and using the decrypted one-time random encryption key to decrypt the message file from the message portion of the return receipt package.
In another embodiment a method for generating a public key portion of a public key/private key pair is provided, comprising: receiving a pass-phrase; and generating the public key portion based at least in part upon the received pass-phrase.
In one example the invention may further comprise: (a) receiving data from at least one of: (i) a unique device, which unique device serves to confirm an identity of a possessor thereof; and (ii) a biometric authenticator, which biometric authenticator reads a unique human attribute; and (b) generating the public key portion based at least in part upon the received pass-phrase and the received data.
In another example the unique device may be one of a smart card and a dongle and the biometric authenticator may be one of a fingerprint reader, a hand geometry reader, and a retinal scanner.
In another embodiment a method for generating a private key portion of a public key/private key pair is provided, comprising: receiving a pass-phrase; and generating the private key portion based at least in part upon the received pass-phrase.
In one example the invention may further comprise: (a) receiving data from at least one of: (i) a unique device, which unique device serves to confirm an identity of a possessor thereof; and (ii) a biometric authenticator, which biometric authenticator reads a unique human attribute; and (b) generating the private key portion based at least in part upon the received pass-phrase and the received data.
In another example the unique device may be one of a smart card and a dongle and the biometric authenticator may be one of a fingerprint reader, a hand geometry reader, and a retinal scanner.
In summary, various embodiments of the present invention provide a mechanism (hereinafter referred to as “System Integrated Security” or “S-I-S”) for the secure storage and/or transmission of information. More particularly, S-I-S may provide security for the “e-world”, enabling businesses and private individuals to avail themselves of the opportunity to use electronic files for the storage and transmission of even the most confidential information. In one example (which example is intended to be illustrative and not restrictive) S-I-S may provide an inexpensive, easy to use, platform-independent suite of products and/or services that provide unique and complete, state-of-the-art electronic file security including one or more of the following elements:
In another example (which example is intended to be illustrative and not restrictive) S-I-S may provide the key to universally accessible, easy to use, platform and application independent, highly effective security for all types of electronic files. More particularly, S-I-S may include:
Of note, the use of S-I-S enabled applications and/or S-I-S enhanced applications (such as optional virus-scanning and independent Time/Date stamping services, for example) may be implemented in another example (which example is intended to be illustrative and not restrictive) as follows:
In another example (which example is intended to be illustrative and not restrictive) S-I-S may include (but not be limited to) the following software products that enable customers to implement and take advantage of the S-I-S architecture:
In another example (which example is intended to be illustrative and not restrictive) S-I-S may include (but not be limited to) the following services (some of which may be outsourced and/or licensed) that enable customers to implement and take advantage of the S-I-S architecture:
Having summarized certain embodiments of the present invention, a discussion of various elements of electronic security according to the present invention will now be undertaken. In this regard, it is noted that certain salient elements of electronic security according to the present invention can be identified by the acronym “CIA&E”. This stands for:
These elements are set out in more detail below as follows
Confidentiality
There are two components to confidentiality:
Content Protection For files that are stored and files that are transmitted, content protection ensures that the contents of those files are accessible only to the entities(s) who should, and who are authorized to, have access to them. Others are prevented from seeing the contents of those files.
Surveillance Protection: Primarily for files that are transmitted, surveillance protection ensures that the existence of a communication between two (or more) entities is known only to those who should, and are authorized to, know of it. Advanced surveillance protection also ensures that confidential files that are stored are as invisible as possible to unauthorized surveillance and monitoring.
Complete confidentiality means that both the content of a secure file and the facts of its existence and/or transmission are known only to those who are intended to know: the file owner(s), the sender, and the recipient(s). Confidential files cannot be read by those not authorized to read them. Transmissions cannot be monitored to know from whom to whom the files (i.e., the communications) are sent.
Integrity
Integrity in an electronic file that is stored and/or transmitted means that when the file is opened and/or received it is the same, complete, unaltered file it was originally. Nothing is added to it, no words, no letters, no spaces, no bits and no deleterious viruses. Nothing is deleted from it, no missing pages, no words, no letters, no spaces and no bits. When a file is stored with integrity, the file, the whole file, and nothing but the file is retrieved when the file is opened. When a file is transmitted with integrity, the file, the whole file, and nothing but the file, is received by the recipient. In the context of information technology, integrity means that when files are securely stored and securely transmitted they cannot be tampered with and altered, and they are protected from viral infection.
Accountability
Accountability—means that the knowledge of: (a) who created, saved, changed, read, deleted, and/or transmitted the file; (b) when the file was saved and/or transmitted; and if the file was transmitted, who opened and/or received the file is available, but only to those authorized to know (that is, those entities who are within the protected circle of confidentiality). An often overlooked, but essential, aspect of accountability is user identity authentication. In the determination of “who”, it is important not only to verify the electronic identity involved in a transaction, but also the actual individual (or group) identity that is behind the electronic identity.
Ease of Use
There is one more attribute that is important for secure computer systems: ease-of-use. In order for a security system to be easy to use, its security procedures and interfaces should be as simple as possible and as similar as possible to those already in use in the normal flow of operations. New procedures and interfaces should be kept to a minimum. If a system is not easy to use then it will not be used as often as it should. And if a system is not used when it should be used, it cannot be effective.
How to Achieve CIA&E
Confidentiality
Content Protection
The heart of content protection is encryption. By encrypting a file, the contents of that file are disguised in such a way that only by decrypting the file are the contents intelligible. Encryption can be thought of as locking a file; decryption as unlocking a file. In accord with the “lock” analogy, both encryption and decryption require the use of a “key” to perform their functions. In electronic encryption/decryption a “key” (either the “encryption key” or the “decryption key”) is a string of bits.
As discussed above, there are two principal types of electronic encryption/decryption:
Surveillance Protection
Gathering valuable intelligence information is not limited only to discovering the contents of confidential files. Knowledge that certain files exist, knowledge of with whom certain files are being shared, and even knowledge of who is communicating with whom, and how often, (without knowing the content of those communications) can all be valuable information. This type of intelligence gathering falls under the general category of “surveillance”. A completely secure file protection system should include protection against these types of surveillance.
Integrity
Digital Signatures and Virus Scanning are the foundations for assuring electronic file integrity. A file that has been digitally signed cannot be tampered with (changed in any way) without invalidating the digital signature. The identity of the signer is also beyond question (“non-repudiation”) as long as the means to affix the signer's digital signature remains only in the hands of that signer. Digitally signed files are comprised of two pieces: the original data file and the digital signature. When a digitally signed file is opened the digital signature can be verified to ensure data file integrity.
Accountability
Accountability is a matter of “Who/Whom”, “What”, and “When”.
“Who”—User Authentication
User Authentication is vital to security. All of security depends upon the correct identification of the individuals and entities involved. Two essential elements for effective authentication are: knowing who requires authentication, and when (under what conditions is) authentication required:
“What & When”—What has Transpired and When
The second aspect of accountability is being able to know what has transpired and when. Part of knowing “what and when” is the maintenance of a separate and independent audit trail. The other part is the recording of the activities, and the time and date of those activities, within a section of the objects of those activities themselves (e.g., a file creation date within the file itself).
“Who & When”—Delivery Acknowledgement
The third aspect of accountability is being able to track documents in transit. An essential element of this is the accountability of the “hand-off”, the passing of a file from one dominion to another. Typically this is accomplished when the receiving party “signs for” the document. Any secure system, whether hardcopy or electronic, must be able to track documents/files with accurate and reliable “signed” return receipts, audit trails of the documents/files in transit.
Ease of Use
A Balance Between Transparency and Awareness
As much as possible, all systems should be easy to use. They should be “transparent” to the extent that they do not get between the user and the tasks that are to be performed. They should not unnecessarily constrain the user. Too often, security systems present the aura of security by creating an unnecessary atmosphere of complexity. On the other hand, in an environment where security measures are not necessary all of the time, it is important that, when security features are being employed, the user is aware of them. More than anything else, effective security is a matter of awareness.
Familiar User Interfaces
Wherever and whenever possible, security systems should utilize familiar user interfaces. The bane of Information Technology (IT) departments is what has sometimes been called the YAAI factor (Yet Another Application Interface). For individuals who have tasks to accomplish, learning yet another user interface, another methodology, another set of steps to be performed, is not a welcome prospect. Security systems that require an entirely new set of procedures run the serious risk of user avoidance.
Flexibility
An effective and viable security system should include and support a wide range of options. The system should enable the users to tune the system to meet their evolving requirements. The same system should be able to handle “low” security environments, “high” security environments, and everything in between.
Referring now to
Taken together, these components enable provide a secure, easy to use, platform independent, and inexpensive computer security system.
More detail regarding each of the components of this embodiment is provided below as follows:
The S-I-S Virtual Strongbox
The foundation of this embodiment of the S-I-S architecture is the secure S-I-S Virtual Strongbox. The S-I-S Virtual Strongbox of this embodiment is the electronic equivalent of a transportable locked strongbox, sealed with a unique, non-reputable seal, and unlockable by only a single specific key. The lock on each of these “strongboxes” can be set to allow only the possessor of the single key, the key owner, to open it (if the Virtual Strongbox is to be used to store the owner's private possessions), or it can be set to allow only a specific recipient to open it (if the Virtual Strongbox is to be used to transport valuables from one person to another).
A value of the S-I-S Virtual Strongbox is that it is secure and portable. Irrespective of the hardware platform and operating system, a secure S-I-S Virtual Strongbox of this embodiment may be stored on any computer, transmitted via any electronic transport medium, and accessed from any computer application that is “S-I-S enabled” (i.e., has the appropriate S-I-S software installed on it). The confidential content of each S-I-S Virtual Strongbox of this embodiment is:
Optionally, the contents may also be:
In addition, each S-I-S Virtual Strongbox of this embodiment contains an audit trail log, a history of all accesses it has experienced (creation, open/read, modify/save, et cetera).
Further, S-I-S Virtual Strongboxes according to this embodiment can be used to store information locally on an end-user's computer, share information in a group (departmental) environment, and exchange/transmit information to outside entities. For example, S-I-S Virtual Strongboxes according to this embodiment can be used as:
When an S-I-S enabled application saves or creates an S-I-S Virtual Strongbox according to this embodiment, the data file is encrypted, digitally signed, optionally time/date stamped and virus scanned, and written into the Virtual Strongbox file together with a secure audit trail (log file) that maintains a history of the files activity. The S-I-S Virtual Strongbox, which may be saved as an “S-I-S” type file on the local operating system, can be stored, copied, and/or transmitted to any other computer. If the Virtual Strongbox is transmitted to another computer, the receiving computer need not be running the same operating system as the sending computer. It merely requires the appropriate S-I-S enabled application (and, of course, the appropriate authenticated authorization, the appropriate “key”) in order to open the S-I-S Virtual Strongbox.
The S-I-S Public Key Repository Network
Whenever an S-I-S user's application must communicate with another S-I-S user, the first S-I-S user must obtain the second user's Public Key. This may be accomplished by a look-up request to the S-I-S Public Key Repository. When a user's application requires another user's Public Key, the application may query its local S-I-S Public Key Repository. If the entry is not found locally, the local S-I-S Public Key Repository may issue a “public” query to all S-I-S Public Key Repositories to which it itself is connected.
S-I-S Public Key Repositories can exist locally and/or remotely, isolated or connected. When a S-I-S Public Key Repository is “connected”, its administrators can determine which entries within it are to be shared with the public network, and which are to be available only to the local domain. One or more parties may maintain an S-I-S Public Key Repository Network Management Service to insure the integrity of all connected S-I-S Public Key Repositories.
The S-I-S Client Software (the S-I-S “Core Module”)
The S-I-S Core Module according to this embodiment is an add-on component for application software. The S-I-S Core Module according to this embodiment contains all of the functionality required to:
When embedded within an application, the S-I-S Core Module according to this embodiment may render that application “S-I-S Enabled”. The requisite interface between the S-I-S Core Module code and some existing software applications may be provided “out of the box” as a convenient add-on component to certain popular computer desktop applications. For other applications, a Software Developer's Kit (SDK) may be utilized to enable software developers to build an interface to the S-I-S Core Module and thus create their own S-I-S Enabled applications.
S-I-S Enhanced Components
In addition to the basic S-I-S components and optional services of this embodiment (e.g., Certified Time/Date Stamp), S-I-S may provide some “enhanced” components, especially designed for those entities that require the utmost in security.
S-I-S Name Randomizer
The S-I-S Name Randomizer according to one embodiment is an S-I-S enhanced component that serves to provide protection against unwanted surveillance intrusion on file storage systems. It does so by disguising file names and/or file owners as listed in operating system directory tables. File names and ownership can, and should, be revealing. With the quantity of information stored and the number of files maintained on computers, it would be totally unmanageable if the file names did not indicate something about the content of their files and who owns them. And yet, even if a malefactor does not have access to the content of a file, knowing the name of a file, that the file exists, and who the owner is, can be valuable information. The S-I-S File Name Randomizer program, according to this embodiment, exists in order to protect against this type of vulnerability.
“Random” File Names
Using an S-I-S Virtual Strongbox, the S-I-S File Name Randomizer program of this embodiment maintains a file-owner-owned translation table (the S-I-S File Name and Ownership Translation Table) that converts between meaningful file Virtual Strongbox names and random (meaningless, disguised and/or misleading) names generated by S-I-S that are seen by the operating system.
Proxy File Ownership
File Proxy Ownership is an S-I-S File Name Randomizer option that, under one embodiment, enables the user to hide the ownership of a Virtual Strongbox file. When this option is installed, the S-I-S File Name Randomizer registers a number of new operating system users. Each of these new users has a “random” name, i.e., a “proxy” name, and identical permissions as the original S-I-S user. The number of proxy names requested may be a user settable parameter (within the limitations set up the by the system administrator). When a new Virtual Strongbox is created, the S-I-S File Name Randomizer saves the Virtual Strongbox file in the operating system, assigning its ownership randomly to one of the file owner's proxy names. Access to the operating system file directory reveals only the proxy name for the file ownership and not the identity of the real owner. When a Virtual Strongbox is opened, the S-I-S File Name Randomizer assumes the identity of the proxy name in order to open the file.
For environments in which strong centralized Information Technology department control is a requirement, S-I-S may render the appropriate file ownership information available to System Administrators.
S-I-S Return Receipt Package—Delivery Acknowledgement Management
When files are transmitted, although it is comforting to know that the file transmission security architecture provides content and surveillance protection, it is also comforting to know that the intended recipient did actually receive them. Indeed, there are times when the acknowledgement of delivery by the recipient is almost as important as the content of the files being transmitted. S-I-S recognizes this essential aspect of “accountability” and provides for it through the use of S-I-S Return Receipt Packages (“S-I-S RR Packages”).
S-I-S Return Receipt Packages
An S-I-S RR Package according to this embodiment is similar to an S-I-S Virtual Strongbox, in that it consists of a number of component files packaged together in a file container, but it is designed to optimize the process of delivery acknowledgement. The S-I-S RR Packages according to this embodiment are divided into two portions: the “message portion” and the “receipt portion”.
Using a four-step protocol according to this embodiment, S-I-S enabled file transmission software (e.g., e-Mail or FTP) ensures that transmitted files cannot be read unless signed for by the recipient. Naturally, all four steps in the process record digitally signed and certified Time/Date stamps. S-I-S enabled file transmission software may support both automatically generated receipt signatures (for more convenience, but less security) and required “manual” receipt signatures (for more security, but less convenience).
Add-On Applications
Using the core S-I-S technology according to the present invention, combined with the S-I-S enhanced components according to the present invention, it is possible to construct and deploy platform and operating system independent secure applications, applications such as:
Of note, the S-I-S technology makes it possible to rise above the protocol minutia, complexity, and platform/OS dependence of more traditional security systems. S-I-S′ application layer architecture makes it possible to use the same security solution for all applications and all environments. S-I-S′ completeness and ease-of-use enables users to use one security system for all of their needs, and not worry about sub-optimized systems that can cause more harm than good.
In another embodiment of the present invention, S-I-S may utilize certain support services, including:
In addition, S-I-S may support significant enhanced application services, such as S-I-S enabled file transmission systems (e.g., e-mail and FTP).
In one embodiment the S-I-S services are be operational essentially 24 hours a day, every day. In order to ensure this level of service, S-I-S may utilize modularity and redundancy. For example (which example is intended to be illustrative and not restrictive), multiple S-I-S SP Nodes (Service Provision centers) may be distributed throughout diverse geographical regions (the S-I-S SP Nodes may be managed centrally from one or more S-I-S Network Operations Centers (NOCs)).
In another example (which example is intended to be illustrative and not restrictive), each of the S-I-S SP Nodes may be located in secure third-party co-hosting facility. The “third party” may be one of the large professional co-hosting entities such as AT&T, IBM, or others. The S-I-S SP Nodes may be designed to balance the load between them and back each other up. The S-I-S SP Nodes may be engineered with enough spare capacity that even if one entire Node is unavailable there will be essentially no service degradation. Each S-I-S SP Node may be linked to the outside world via multiple high-speed communication lines and multiple ISPs.
Referring now to
Of further note, a user may use S-I-S Virtual Strongboxes to store private information, accessible only by the Virtual Strongbox's creator, or to create Virtual Strongboxes for others, Virtual Strongboxes that only their new owners may open. Virtual Strongboxes thus become the medium for both secure information storage and secure information transmission.
Regarding ownership of the Virtual Strongboxes, it is noted that in this embodiment each Virtual Strongbox has one owner. More particularly, as seen in
Note, it is also possible to create a Mixed Group Entity. A “mixed group”, entity is a group in which some members are Group Entities, Group Identities, Individual Identities, and/or Individual members of a Group Membership. This mix-and-match capability enables significant flexibility for data access when, for example, “any three out of five” entities are required for access.
Referring now to authentication according to an embodiment of the present invention it is noted that there are two principal types of Authentication: Registration Authentication, and Access Authentication. More particularly:
Within the context of S-I-S according to this embodiment, “Who” is an entity that can be of any of the different types of S-I-S Virtual Strongbox owner classes: Individual Identity, Group Identity, Group Membership, and Group Entity. “How” is dependent upon the owner class and the specific entity's authentication profile. “When” is dependent upon how the particular S-I-S installation is set up and the individual configuration of specific Virtual Strongboxes.
There are two types of “When” Authentication:
The “How” Authentication Options determine the criteria used to authenticate (identify) the End User. S-I-S uses three classes of “How” criteria:
Note, according to this embodiment these options are not mutually exclusive. Pass Phrase authentication is always required, but it can be used either alone or in conjunction with one, or both, of the other options.
“Who” authentication is very much dependent upon the nature of “who” is being authenticated. Individual authentication can have different criteria than group authentication. In this embodiment, there are four classes of identity. The “who” authentication of each is explained in the following:
Referring now to
All Virtual Strongbox access may be recorded in an Audit Trail file. When the Virtual Strongbox is created in this embodiment, an audit trail profile is created. This may determine what actions are to be recorded to the audit trail. Each audit trail entry according to this embodiment contains:
In addition, an audit trail entry may contain optional fields such as:
Referring once again to the Internal Log file of this embodiment, it is noted that this is a file that is stored inside of each Virtual Strongbox. It is encrypted with the Virtual Strongbox owner's Public Key so that only the Virtual Strongbox owner may read it. It is also digitally signed by the individual who writes/saves the Virtual Strongbox. This digital signature helps protect the Internal Log file from tampering.
Referring once again to the External Log file of this embodiment, it is noted that this is a file stored in the operating system of the computer that stores the Virtual Strongbox. In this registered user. The S-I-S External Audit Trail file is managed by the S-I-S Core Module and is operating system per computer. The S-I-S External Audit Trail file is owned by the S-I-S embodiment there is only one S-I-S Audit Trail (“Log”) file per S-I-S registered user per encrypted with the S-I-S External Audit Trail owner's Public Key. Thus, only the S-I-S External Audit Trail's owner can read its contents. Naturally, since the External Log may contain entries from multiple Virtual Strongboxes, all owned by the same owner, each External Log entry contains an additional field indicating to which Virtual Strongbox the entry pertains. Of note, the External Log will contain one type of entry that cannot appear in the Internal Log—the entry that records the deletion of the Virtual Strongbox file.
In addition, for greater security it is also possible to record, in a System Administrator owned S-I-S Audit Log file, all access, and attempted access, to specific S-I-S “External Log” files. This additional audit trail can help prevent malicious activities specifically directed at particular S-I-S Audit Trail files.
Referring now
An S-I-S RR Package is similar to an S-I-S Virtual Strongbox, in that it consists of a number of component files packaged together in a file container, but it is designed to optimize the process of delivery acknowledgement. In this embodiment the S-I-S RR Packages are divided into two portions: the “message portion” and the “receipt portion”.
As seen in this
Further, as seen in this
Referring now
More particularly:
Step 1—The Sender Sends the Package
When an S-I-S user (the “Sender”) transmits a file (the “Message File”) to another S-I-S user (the “Recipient”) using S-I-S enabled software and the S-I-S Return Receipt option, the S-I-S software creates an S-I-S RR Package. Within the S-I-S RR Package are, among other items:
Of note, the entire S-I-S RR Package is transmitted to the Recipient and the S-I-S RR Package is also recorded as “sent” in the Sender's S-I-S RR Transmission Log (which may be an S-I-S Virtual Strongbox file).
Step 2—The Recipient Returns the Receipt
On the Recipient's computer, the S-I-S enabled software opens the S-I-S RR Package. The software then:
Step 3—The Sender Sends the Release
When the Sender receives the Receipt, the S-I-S enabled transmission software:
Step 4—The Release is sent to the Recipient
When the Recipient receives the Release, the S-I-S enabled software:
Referring now to
Depending upon the volume of Delivery Acknowledgement (Return Receipt) traffic received and the nature of the communications, a Recipient may find that the manual acknowledgement of each and every Return Receipt transmission is an overly onerous and unnecessary task. In this embodiment the Recipient has the option to set S-I-S RR Receipt response to “Implicit”, i.e., to automatically send the return receipt without any human intervention. There is, however, a price for this convenience. Messages are “signed for” without the Recipient's knowledge (i.e., information is being transmitted from the recipient's computer without the recipients explicit consent) and the “Receipt” Signature may not be legally binding. In any case as seen in this
As might be expected, the Sender of an S-I-S RR Package may not want merely an Implicit Return Receipt Signature. This embodiment therefore provides the Sender with an option that forces the Recipient to provide an Explicit Signature. When the Sender specifies the “Explicit Return Receipt Signature” option, the S-I-S enabled recipient software of this embodiment will only accept an Explicit Signature, an explicit response.
Of note, S-I-S enabled file transmission software of this embodiment can send the transmitted file either directly (Sender to Recipient—“Point to Point”) or indirectly via an intermediary (a “Third Party Service Provider). Depending upon the specific application, there are advantages and disadvantages to each. When sending an S-I-S RR Package transmission through a Third Party Service Provider, the Sender has the option of managing the return receipt directly, or of requesting that the Secure Third Party Service (e.g., a Secure e-Mail Service) manage it. This option is set up as a user preference that can be changed on a per message basis.
The basis for S-I-S's encryption and digital signature features according to an embodiment of the present invention involves asymmetric encryption; in particular Public and Private keys. This technology is colloquially known as “Public Key Infrastructure” or “PKI”. Under PKI, each entity using the system has a unique pair of encryption/decryption keys. One key is the “Public Key”. As its name implies, the Public Key is public. Its value can be shared with the world. The other Key is the “Private Key”. The Private Key should be known only to the owner of the key.
The two predominate methods of assigning PKI Keys according to this embodiment are:
S-I-S, according to this embodiment, can work with PKI keys generated by and obtained from a Trusted Third Party Vendor. For optimum security, however, native S-I-S works best with S-I-S PKI keys generated on the key owner's computer. Native S-I-S key generation may be based upon the identity authentication information provided by the user. S-I-S Core Module software provides the functionality for generating these Public/Private Key pairs. Since these keys need not be stored in non-volatile memory, an S-I-S user may be able to use any S-I-S enabled computer, not merely the computer in which his/her PKI keys are stored. S-I-S may store Public Keys on key owner's computers, but never Private Keys.
In order to send secure information to others using PKI technology, or to validate a digital signature, it is sufficient to know the other entity's Public Key. S-I-S registered Public Keys are stored in a network of S-I-S Public Key Repositories. These S-I-S Public Key Repositories are accessible by the S-I-S Core Module programs.
When an S-I-S key owner first registers with S-I-S, the Public Key is recorded in an S-I-S Public Key Repository. Within each S-I-S Public Key Repository, it can be specified which Public Keys are to be shared with the general public and which are to known only to the local members of the repository. It is also possible within a single repository to set up multiple domains of Public Keys, so that, on a key by key basis it is possible to specify which key to share, or not share, and with which domains.
In order to maintain consistency and the integrity of the S-I-S Public Key Repository Network, an oversight entity may maintain an S-I-S Public Key Repository Network Management Service. In one embodiment all S-I-S Public Key Repositories must subscribe to this oversight service.
Further, S-I-S according to this embodiment provides support for some of the more popular non-S-I-S PKI systems. The S-I-S Core Module contains the functionality to interface with these non-S-I-S vendors. When working with a non-S-I-S PKI System, S-I-S obtains the required PKI key pairs, either from those stored on the S-I-S user's computer or from those the PKI vendor makes available to the public.
The following discussion will now focus on certain additional S-I-S components according to an embodiment of the present invention:
S-I-S Virus Scanner Interface
The spread of computer viruses has reached pandemic proportions. The use of encryption may, unless the proper precautions are taken, adversely contribute to the unchecked spread of these destructive programs. If a file in encrypted, and that file contains a virus, the virus will also be encrypted. Firewalls and other corporate level defenses cannot readily detect encrypted viruses (and thus, such defenses let encrypted viruses pass through unimpeded—see
More particularly, Virtual Strongbox files can be scanned just before they are encrypted and written into the Virtual Strongbox. They can be scanned again, when the Virtual Strongbox is opened and its contents decrypted, but before the individual files are themselves opened. When the S-I-S Virus Scanner Interface option is active, the S-I-S Core Module may perform these functions automatically. Whenever a Virtual Strongbox is opened or saved (or if a Virus Scan is requested by the user), the S-I-S Core Module searches for presence of an S-I-S enabled Virus Scanner. When it finds one, it submits the Virtual Strongbox contents to the Virus Scanner to be scanned. If an S-I-S enabled Virus Scanner is not found, the S-I-S Core Module issues an error message and requests guidance from the user. The user may opt to try again or cancel the Virus Scanning operation. In this embodiment, for this S-I-S option to function effectively, the user must maintain, or have access to, an up-to-date S-I-S enabled virus scanner program, accessible from the user's computer.
S-I-S Time/Date Stamp Interface
Inaccurate time/date stamps can lead to confusion. Deliberately altered time/date stamps can be used as tools for fraud and deceit. It is easy, for those who know how, to manipulate and alter the time/date stamp on their own computers. For true and accurate, impartial, time/date stamps, an independent third party may be necessary. The S-I-S Time/Date Stamp Interface of this embodiment works with S-I-S enabled independent Time/Date providers to record digitally signed, independently certified time/date stamps in the S-I-S Virtual Strongboxes. When the S-I-S Time/Date Stamp Interface option is active in this embodiment, before the S-I-S Core Module records a time/date stamp, it attempts to find an S-I-S enabled Time/Date provider and obtain a certified, digitally signed, time/date stamp from that provider. If it cannot find such a provider, it issues an error message and requests guidance from the user. The user may opt to try again, cancel the operation, or use the local computer's (not certified) time/date stamp.
S-I-S File Name Randomizer
File names and ownership can, and should, be revealing. With the quantity of information stored and the number of files maintained on computers, it would be totally unmanageable if the file names did not indicate something about the content of their files and who owns them. And yet, even if a malefactor does not have access to the content of a file, knowing the name of file, that the file exists, and who the owner is, can be valuable information. In order to protect against this type of vulnerability, this embodiment of S-I-S provides an S-I-S File Name Randomizer program. Using an S-I-S Virtual Strongbox, the S-I-S File Name Randomizer program maintains a file-owner-owned translation table (the S-I-S File Name and Ownership Translation Table) that converts between meaningful Virtual Strongbox file names and random meaningless names, generated by S-I-S, that are seen by the operating system. When a new Virtual Strongbox is created, the S-I-S File Name Randomizer:
When the user wishes to open a Virtual Strongbox and the S-I-S File Name Randomizer is operating, the user consults the list of meaningful Virtual Strongbox names in the translation table. Upon choosing one, the S-I-S File Name Randomizer issues a command to the operating system to open the file (the Virtual Strongbox file) with the corresponding random name.
Of note, when the S-I-S File Name Randomizer assigns a “random name” to a Virtual Strongbox file, it can, at the user's option, also disguise the “type” of file (i.e., it can alter the file suffix as well as the file name).
File Proxy Ownership
File Proxy Ownership is an S-I-S File Name Randomizer option that enables the user to hide the ownership of a Virtual Strongbox file. When this option is installed, the S-I-S File Name Randomizer registers a number of new operating system users. Each of these new users has a “random” name, i.e., a “proxy” name, and identical permissions as the original S-I-S user. The number of proxy names requested is a user settable parameter (within the limitations set up by the system administrator). When a new Virtual Strongbox is created, the S-I-S File Name Randomizer saves the Virtual Strongbox file in the operating system, assigning its ownership randomly to one of the file owner's proxy names. Access to the operating system file directory reveals only the proxy name for the file ownership and not the identity of the real owner. When a Virtual Strongbox is opened, the S-I-S File Name Randomizer assumes the identity of the proxy name in order to open the file.
Centralized Control File Proxy Ownership
For some IT environments, the free-wheeling, decentralized control provided by the standard S-I-S File Proxy Ownership may be too lax. These environments may require stronger centralized control, control that permits the System Administrators to know who the real file owners are. For such environments, a variation on the standard S-I-S File Name Randomizer program may be provided: the S-I-S Centralized File Name Randomizer (CFNR). In a CFNR environment, in addition to each user maintaining his/her own S-I-S File Name and Ownership Translation Table, the operating system maintains a table for the entire user population: the Global File Name and Ownership Translation Table. Unlike the standard S-I-S File Name and Ownership Table, this table is not a Virtual Strongbox, since all users must have access to it. In one example (which example is intended to be illustrative and not restrictive) the “Global Table” contains five columns: Meaningful File Name, Randomized File Name, File Owner's Proxy Name, File Owner's Real Name, File Owner's Digital Signature. In order to preserve confidentiality, certain columns of each entry of the table are encrypted. These are as follows:
Since the System Administrator's Public Key is known, each user can write his/her own entries into the table. Since the Meaningful File Name column is encrypted with the File Owner's Public Key, only the File Owner can know its value. The two plain text fields contain information that is available in the operating system directories. The File Owner's Real Name is accessible only to the System Administrator. The File Owner's Digital Signature prevents bogus table entries.
Of note,
A discussion of how an certain embodiments of the S-I-S architecture may provide various aspects of CIA&E (discussed above) will now be undertaken:
How S-I-S Protects Confidentiality There are two aspects to Confidentiality: Content Protection and Surveillance Protection.
Content Protection
S-I-S protects the content of Virtual Strongboxes by encrypting the content. The encryption used may be the strongest encryption permissible by law. When the laws change and/or the technology improves, S-I-S may incorporate those changes. Using Public/Private Key technology S-I-S ensures, to the maximum extent possible, that only the entity possessing the appropriate Private Key can decrypt and read the files stored in a Virtual Strongbox. This is true of Virtual Strongboxes that are stored and of Virtual Strongboxes that are transmitted (the technology may be the same; the encryption may be the same; the protection may be the same—the Virtual Strongboxes may be same).
Surveillance Protection
S-I-S provides significant protection against surveillance of stored files and against surveillance of transmitted files.
Surveillance Protection for Stored Files
The S-I-S File Name Randomizer helps ensure the anonymity of stored files. Snoopers are only able to determine that files exist on storage devices. They cannot determine the true names of the files, the types of the files (are they Virtual Strongboxes?), nor the owners of the files.
Surveillance Protection for Transmitted Files
For transmitted S-I-S Virtual Strongboxes, the use of an intermediate destination, such as an S-I-S enabled e-Mail Service, ensures the de-coupling of sender and receiver for any surveillance of the transmission media. Transmission monitors are only able to detect that the sender has transmitted some information (its name and content unknown), not to whom it is being sent (except that it was sent to the neutral intermediate station). Similarly transmission monitors are only able to detect that the receiver has received some information (its name and contents unknown), not from whom it came (except that it came from the neutral intermediate station).
How S-I-S Protects Integrity
File Integrity is a function of tamper-proofing and virus protection. S-I-S provides both. The extensive use of digital signatures ensures that Virtual Strongbox files and S-I-S support files are not tampered with. The optional Virus Scanning at critical points in a file's existence (i.e., on opening, on saving, and during transmission) minimizes the danger of virus infection and renders the limiting factor the capability of the Virus Scanner software, rather than the S-I-S architecture.
How S-I-S Provides Accountability
As it is stated above: Accountability is a matter of “Who/Whom”, “What”, and “When”. S-I-S answers and keeps track of all of this accountability information, ensures its accuracy, and protects the information.
“Who”
S-I-S supports both aspects of “Who” Accountability:
“What & When”
S-I-S's multiple Audit Trail files, one stored within each Virtual Strongbox itself, keep accurate and secure track of all that transpires within the S-I-S system and its Virtual Strongboxes.
The use of digitally signed, independent, certified Time/Date stamps provide S-I-S users with accurate records of “when” events occurred.
“Who & When”—Delivery Acknowledgement
The S-I-S Return Receipt Package and its supporting software provide a reliable, easy-to-use (low administrative overhead), and well-protected Return Receipt mechanism.
Why S-I-S is Easy to Use
S-I-S is easy to use because it provides the appropriate balance between transparency and awareness. The transparency is a result of the S-I-S customized interfaces with existing applications. S-I-S may thus be “built into” those already familiar applications. In one embodiment it is not a whole new system, a whole new paradigm, nor a whole new user interface. By being designed, in one embodiment, as an “add-on” component, S-I-S functionality integrates directly into known workflow and activity patterns. The learning curve is thus anything but steep.
Nevertheless, the awareness is there. There may be “extra buttons” on computer screens and additional functionality to think about. When a legal digital signature is required, S-I-S may prompt for it. Security with S-I-S is a gentle presence, not an overbearing burden.
S-I-S is easy to use because it is flexible. In one embodiment S-I-S builds its security at the application layer, not the operating system layer. This means that S-I-S may be easily operating system and machine independent. S-I-S Virtual Strongboxes can be created, read, saved, and sent on any computer that is running S-I-S enabled software. S-I-S Virtual Strongboxes can travel across any network (including wireless) and through any computer, whether or not it is S-I-S enabled. S-I-S avoids the messy inter-system protocols that complicate communications. S-I-S can stay ahead of the technology wave, riding, as it does, in one embodiment, as an application, above all of the operating system turbulence and dependencies.
S-I-S is easy to use because it is robust. It can support many levels of security requirements, from the most stringent to the most lax, with a level of complexity (although always low) commensurate with the security requirements of the environment.
As discussed above, authentication is an important aspect of security. Thus, it deserves some additional detailed attention. In general, authentication is the means whereby system users are identified (that is, authentication is verification of identity). In one embodiment of the present invention there are three distinct types of authentication that correspond to the three distinct situations when authentication is required:
In order to understand the implications and vulnerabilities of each, it is important to understand how each type of authentication is accomplished.
How is Authentication Accomplished?
Registration Authentication
Registration Authentication occurs when an individual is enrolled as a system user and receives a system identity. This system identity is familiar to most computer users as being their system “login name”. In many, perhaps most, public systems, Registration Authentication is the least stringent of the authentication processes, and the source of significant vulnerability.
Within the corporate environment, Registration Authentication typically begins with a manual process, usually a Human Resources function. An employee is hired by the company. Forms are filled out and references are checked. If no problems arise, the individual is then assumed to be the person whom he/she has presented him/herself to be. Once the corporate identity has been established, an Information Technology department system administrator typically registers the individual into the system (or systems) to which he/she will have access.
Outside of the controlled corporate environment most Registration Authentication is based upon self-affirmation, “I am who I am because I say that I am.” For example, almost any individual can register with almost any Internet Service Provider and create almost any identity he/she desires. That identity, whether real or fictional, whether true or stolen, then takes on an existence all its own. It will appear in shared mailing lists and in Internet based directories. A de facto identity is created, based purely on the Registration Authentication of self-affirmation.
Third party identification authentication (e.g., a notary) is also possible.
External (Access) Authentication
External, or “Access”, Authentication occurs when an entity must establish an identity at the start of a new “system session”. This can be at the start of a computer usage session (the familiar “Login” screen at system startup) or at the start of a new “session” that requires re-identification (such as is required when accessing a secure area of a web site). External Authentication is used to verify the identity of the entity attempting to use the system. These verification criteria can be as simple as the requirement for a password, or PIN, and as complex as requiring multiple individuals using biometric devices. Typically, External Authentication uses three types of criteria:
Internal Authentication
As computer system users work with their systems, they periodically require access to various system resources. Prior to granting access to a resource, the computer system must determine whether or not the particular user has the permission/authority to access the requested resource. Permissions and authority are a function of identity.
Explicit Internal Authentication—Permission Lists
After External Authentication has taken place, systems typically assign the system user an internal system ID. This internal system ID serves to identify that user in all future system interactions (within the session). The internal system ID is then compared with “permission” lists to determine what privileges the user has and to what information the user should be granted access.
Using permission lists to control resource access implies the need for a central authority. Ultimate control will always reside with whoever has the authority to maintain the lists. The use of permission lists thus mandates a hierarchical privilege structure.
Implicit Internal Authentication—Encryption
An alternative and/or supplement to the use of access permission lists is the use of encryption and “keys” to perform internal authentication. Using this method, the user is associated with one or more “keys”. These keys are used for the encryption and decryption of information. Access permission is determined by whether or not the user's keys can correctly decrypt the information.
Key-based access control can be managed by a central authority, the assigner of the keys, or individually, when keys are generated by the individuals who use them. Keys can be used to support both a centralized hierarchical privilege structure and/or a flat, decentralized, egalitarian, privilege structure.
Referring now to the operation of conventional secure file transmission systems, a discussion of secure e-mail utilizing a Point-to-Point Encryption architecture and a Web Based Secure e-Mail architecture will be undertaken (of note, a similar analysis can be performed for File Transfer Protocol [FTP], Electronic Data Interchange [EDI], or other “secure” information transmission systems).
More particularly, referring now to
In the example shown in
Disadvantages of Conventional Point-to-Point Encryption
If Point-to-Point Encryption Systems are well implemented they provide a certain degree of security. How good are they in terms of the total picture of the CIA&E criteria?
Some of these limitations of conventional Point-to-Point Encryption systems are illustrated in
Perhaps even more troubling is the notion that Alice's messages, although tamper-proof and not subject to repudiation, can contain and spread viruses. If Alice's message to Bob contains a virus, either inadvertently or maliciously, the virus itself will be encrypted and therefore it is not detectable by the firewalls' virus scanners.
When using Point-to-Point Encryption, there is nothing to prevent Alice from entering a fraudulent Time/Date stamp on her e-mail before sending it to Bob. Without recourse to independent verification, Bob cannot know, or prove, that the e-mail was not sent when Alice says it was.
Referring now to
In order to send a secure e-Mail message to Bob, Alice logs on to the web site of a Web Based Secure e-Mail provider. She establishes a secure link (SSL) to the web site and enters her e-mail message. She also typically provides a password that Bob must use in order to authenticate himself when he retrieves the message.
On the web site, the message is Time/Date stamped and may be scanned for viruses. It is then encrypted and stored on the web server. An “open” (non-encrypted) e-mail message is sent to Bob informing him that he has a secure e-mail message from Alice, and instructing him on how to retrieve it.
Bob logs on to the web site and provides the appropriate password, which he has received from Alice via another medium. The message is then decrypted and Bob can read it. Bob's retrieval of the message is also Time/Date stamped and then transmitted to Alice (possibly in a secure e-mail message, but usually in another “open” e-mail).
Disadvantages of Conventional Web Based Secure e-Mail
Web Based Secure e-Mail Systems are becoming more and more popular, although the efficacy of their security is typically not great. How are they in terms of the total picture of the CIA&E criteria?
Some of the limitations of Web Based e-Mail Systems are illustrated in
Referring now to
The overall process of sending a secure e-Mail message consists of three components: the sender, the recipient, and a Mid-Station processing center. The sender has two Mid-Station Processing Options: to send the e-Mail with or without Integrity Checking.
Option #1—Mid-Station Integrity Checking
Option #2—Mid-Station Pass Through (No Integrity Checking)
Of note, there are advantages to each option. In general Option #1 is more convenient (no requirement to maintain a completely up-to-date Virus Scanner), but Option #2 is more secure (no intermediate decryption of the Virtual Strongbox by a third party).
Of further note, a “Registered Mail” (Return Receipt) Option may be provided since confidential communications often require a delivery confirmation and/or an acknowledgement of receipt by the recipient.
Of further note, this embodiment of the present invention may require the following:
Of further note, as seen in
Confidentiality
The aspects of confidentiality are Content Protection and Surveillance Protection. This embodiment of the secure e-mail System does both.
Integrity
Integrity is preserved through the use of digital signatures (tamper-proofing) and viable virus scanning; virus scanning of a plain text (not a cipher text) message.
Accountability
The conditions of accountability are also met. These are:
Ease of Use
The use of modular client software that functions as an add-on to existing e-mail clients ensures that system users will be working with a familiar user interface. Since it is compatible with an “on-demand” key generation system, users of this secure e-mail system are not tied to using any particular computer for their e-mail. Any computer in which the appropriate e-mail client enhancement is installed can be used. Security levels can be as lax or as stringent as desired and required. The flexibility exists for some subscribers to use simple Pass Phrase authentication, while others use a combination that includes unique devices, biometrics, and even duress codes.
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
In another embodiment of the present invention S-I-S is a platform independent security architecture that provides protection for electronic information storage and transmission.
In another embodiment of the present invention S-I-S is a shared, high availability, high performance, complete, effective, and easy to use electronic security architecture.
In another embodiment of the present invention the S-I-S architecture, and the extent and effectiveness of its security, are unique in the marketplace.
In another embodiment the present invention provides a security mechanism which is:
In another embodiment of the present invention the S-I-S applications may include, but are not limited to:
In another embodiment of the present invention a revenue model associated with the electronic information security mechanism may utilize one or more of the following revenue stream types according to the implementation of the invention (e.g., the type of product or service being sold):
In another embodiment of the present invention a mechanism may be provided for information storage and transmission which enables entities to store and/or retrieve information efficiently; to communicate quickly; and to operate in a secure and low cost fashion.
In another embodiment of the present invention a mechanism may be provided for a shared, high availability, high performance, complete, effective, easy to use, and platform independent security architecture.
In another embodiment of the present invention a mechanism may be provided for universal, platform and application independent, security software. The software's completeness and ease of use may render it an effective electronic file security system.
In another embodiment of the present invention a mechanism may be provided for a platform-independent system architecture that provides the foundation for complete and secure electronic file storage and/or transmission.
In another embodiment of the present invention a mechanism may be provided for universal and secure interconnectivity.
In another embodiment of the present invention the same technology may be used to protect files that are stored and files that are transmitted.
In another embodiment of the present invention a mechanism may be provided for the protection across the spectrum of electronic security: Confidentiality, Integrity, Accountability, and Ease of Use.
In another embodiment of the present invention a combination of Symmetrical and Asymmetrical encryption may be used to protect the content of confidential files.
In another embodiment of the present invention the virtual strongboxes may contain additional files (wherein hooks are provided in the virtual strongboxes to aid in downward and/or cross-platform compatibility).
In another embodiment of the present invention each virtual strongbox may be named with the same name as a data file contained therein (including the suffix), with a unique (for example, but not limited to, “.vsb”) suffix appended thereto (e.g., if a data file is a Microsoft Word document called “myword.doc”, then the virtual strongbox containing this Word document may be named “myword.doc.vsb”).
In another embodiment of the present invention the “random” names (e.g., in connection with a file name and/or a file owner alias) may be generated from either totally random (e.g., pseudo) combination of characters, or from a combination of random characters and predetermined character strings. One reason for this is that if a file name has a completely unintelligible name (e.g., AcI9xowq.doc), it may be readily recognizable as a disguised file; on the other hand, if the file has an innocuous looking name (e.g., Soccer League Roster 23.doc), it will far less conspicuous, and hence, better hidden.
While a number of embodiments of the present invention have been described, it is understood that these embodiments are illustrative only, and not restrictive, and that many modifications may become apparent to those of ordinary skill in the art. For example, any aspect(s) of the invention may be implemented, as desired, as software, firmware, and/or hardware.
| Patent | Priority | Assignee | Title |
| 10033533, | Aug 25 2011 | DocuSign, Inc. | Mobile solution for signing and retaining third-party documents |
| 10069852, | Nov 29 2010 | BIOCATCH LTD | Detection of computerized bots and automated cyber-attack modules |
| 10146957, | Jan 27 2006 | APPRISS RETAIL INFORMATION LLC | Sensitive data aliasing |
| 10198418, | Jul 18 2007 | DocuSign, Inc. | Systems and methods for distributed electronic signature documents |
| 10210488, | Jun 28 2001 | CheckFree Services Corporation | Inter-network financial service |
| 10289813, | Sep 27 2007 | United Services Automobile Association (USAA) | Systems and methods for secure online repositories |
| 10430570, | Jul 14 2011 | DocuSign, Inc. | System and method for identity and reputation score based on transaction history |
| 10432394, | Mar 09 2010 | KL DATA SECURITY PTY LTD | Method and system for sharing encrypted content |
| 10474815, | Nov 29 2010 | BIOCATCH LTD | System, device, and method of detecting malicious automatic script and code injection |
| 10511732, | Aug 25 2011 | DOCUSIGN, INC | Mobile solution for importing and signing third-party electronic signature documents |
| 10523680, | Jul 09 2015 | BIOCATCH LTD | System, device, and method for detecting a proxy server |
| 10558684, | Feb 25 2011 | International Business Machines Corporation | Auditing database access in a distributed medical computing environment |
| 10579784, | Nov 02 2016 | BIOCATCH LTD | System, device, and method of secure utilization of fingerprints for user authentication |
| 10586036, | Nov 29 2010 | BIOCATCH LTD | System, device, and method of recovery and resetting of user authentication factor |
| 10614244, | Jan 27 2006 | APPRISS RETAIL INFORMATION LLC | Sensitive data aliasing |
| 10621585, | Nov 29 2010 | BIOCATCH LTD | Contextual mapping of web-pages, and generation of fraud-relatedness score-values |
| 10685355, | Dec 04 2016 | BIOCATCH LTD | Method, device, and system of detecting mule accounts and accounts used for money laundering |
| 10719765, | Jun 25 2015 | BIOCATCH LTD | Conditional behavioral biometrics |
| 10728761, | Nov 29 2010 | BIOCATCH LTD | Method, device, and system of detecting a lie of a user who inputs data |
| 10747305, | Nov 29 2010 | BIOCATCH LTD | Method, system, and device of authenticating identity of a user of an electronic device |
| 10776476, | Nov 29 2010 | BIOCATCH LTD | System, device, and method of visual login |
| 10785383, | Jan 29 2016 | Xerox Corporation | System and method for managing security settings of a print device using a lockdown mode |
| 10791196, | Aug 29 2017 | Amazon Technologies, Inc | Directory lookup for federated messaging with a user from a different secure communication network |
| 10832234, | Apr 15 2011 | Huawei Technologies Co., Ltd. | Wireless payment with a portable device |
| 10834090, | Jul 09 2015 | BIOCATCH LTD | System, device, and method for detection of proxy server |
| 10834590, | Nov 29 2010 | BIOCATCH LTD | Method, device, and system of differentiating between a cyber-attacker and a legitimate user |
| 10897482, | Nov 29 2010 | BIOCATCH LTD | Method, device, and system of back-coloring, forward-coloring, and fraud detection |
| 10917431, | Nov 29 2010 | BIOCATCH LTD | System, method, and device of authenticating a user based on selfie image or selfie video |
| 10949400, | May 09 2018 | WELLS FARGO BANK, N A | Systems and methods for tamper-resistant activity logging |
| 10949503, | Sep 27 2007 | United Services Automobile Association (USAA) | Systems and methods for secure online repositories |
| 10949514, | Nov 29 2010 | BIOCATCH LTD | Device, system, and method of differentiating among users based on detection of hardware components |
| 10949757, | Nov 29 2010 | BIOCATCH LTD | System, device, and method of detecting user identity based on motor-control loop model |
| 10970394, | Nov 21 2017 | BIOCATCH LTD | System, device, and method of detecting vishing attacks |
| 11055387, | Jul 14 2011 | DocuSign, Inc. | System and method for identity and reputation score based on transaction history |
| 11055395, | Jul 08 2016 | BIOCATCH LTD | Step-up authentication |
| 11138587, | Apr 15 2011 | Huawei Technologies Co., Ltd. | Wireless payment with a portable device |
| 11159310, | Jul 16 2012 | Amazon Technologies, Inc | Digital security bubble |
| 11188646, | Sep 01 2016 | Cylance Inc. | Training a machine learning model for container file analysis |
| 11210394, | Nov 21 2016 | Cylance Inc. | Anomaly based malware detection |
| 11210674, | Nov 29 2010 | BIOCATCH LTD. | Method, device, and system of detecting mule accounts and accounts used for money laundering |
| 11223619, | Nov 29 2010 | BIOCATCH LTD.; BIOCATCH LTD | Device, system, and method of user authentication based on user-specific characteristics of task performance |
| 11238349, | Jun 25 2015 | BIOCATCH LTD | Conditional behavioural biometrics |
| 11250435, | Nov 29 2010 | BIOCATCH LTD | Contextual mapping of web-pages, and generation of fraud-relatedness score-values |
| 11263299, | Jul 14 2011 | DocuSign, Inc. | System and method for identity and reputation score based on transaction history |
| 11269977, | Nov 29 2010 | BIOCATCH LTD | System, apparatus, and method of collecting and processing data in electronic devices |
| 11283818, | Sep 01 2016 | Cylance Inc. | Container file analysis using machine learning model |
| 11314849, | Nov 29 2010 | BIOCATCH LTD | Method, device, and system of detecting a lie of a user who inputs data |
| 11323451, | Jul 09 2015 | BIOCATCH LTD | System, device, and method for detection of proxy server |
| 11330012, | Nov 29 2010 | BIOCATCH LTD. | System, method, and device of authenticating a user based on selfie image or selfie video |
| 11349659, | Aug 29 2017 | Amazon Technologies, Inc | Transmitting an encrypted communication to a user in a second secure communication network |
| 11368442, | Aug 29 2017 | Amazon Technologies, Inc | Receiving an encrypted communication from a user in a second secure communication network |
| 11373177, | Oct 26 2016 | CPLABS, INC | Method for issuing currency and making payment using utxo-based protocol and server using same |
| 11425563, | Nov 29 2010 | BIOCATCH LTD | Method, device, and system of differentiating between a cyber-attacker and a legitimate user |
| 11457018, | Aug 29 2017 | Amazon Technologies, Inc. | Federated messaging |
| 11489675, | Jul 12 2019 | ALLSCRIPTS SOFTWARE, LLC | Computing system for electronic message tamper-roofing |
| 11580553, | Nov 29 2010 | BIOCATCH LTD. | Method, device, and system of detecting mule accounts and accounts used for money laundering |
| 11586711, | May 14 2018 | Cisco Technology, Inc | Systems and methods for securing and controlling access to electronic data, electronic systems, and digital accounts |
| 11593317, | May 09 2018 | PALANTIR TECHNOLOGIES INC. | Systems and methods for tamper-resistant activity logging |
| 11606353, | Jul 22 2021 | BIOCATCH LTD | System, device, and method of generating and utilizing one-time passwords |
| 11790061, | Jul 14 2011 | DocuSign, Inc. | System and method for identity and reputation score based on transaction history |
| 11818277, | Jul 12 2019 | ALLSCRIPTS SOFTWARE, LLC | Computing system for electronic message tamper-proofing |
| 11838118, | Nov 29 2010 | BIOCATCH LTD. | Device, system, and method of detecting vishing attacks |
| 7519825, | Jan 17 2005 | House of Development LLC | Electronic certification and authentication system |
| 7617251, | Nov 17 2004 | MICRO FOCUS LLC | Systems and methods for freezing the state of digital assets for litigation purposes |
| 7680801, | Nov 17 2004 | MICRO FOCUS LLC | Systems and methods for storing meta-data separate from a digital asset |
| 7707642, | Aug 31 2004 | Adobe Inc | Document access auditing |
| 7716191, | Nov 17 2004 | MICRO FOCUS LLC | Systems and methods for unioning different taxonomy tags for a digital asset |
| 7756842, | Nov 17 2004 | MICRO FOCUS LLC | Systems and methods for tracking replication of digital assets |
| 7792757, | Nov 17 2004 | MICRO FOCUS LLC | Systems and methods for risk based information management |
| 7809699, | Oct 31 2006 | MICRO FOCUS LLC | Systems and methods for automatically categorizing digital assets |
| 7814062, | Nov 17 2004 | MICRO FOCUS LLC | Systems and methods for expiring digital assets based on an assigned expiration date |
| 7849512, | Mar 21 2005 | ID 8 FUND, LP | Method and system to create secure virtual project room |
| 7958148, | Nov 17 2005 | MICRO FOCUS LLC | Systems and methods for filtering file system input and output |
| 8056136, | Nov 01 2010 | Kaspersky Lab Zao | System and method for detection of malware and management of malware-related information |
| 8239496, | Mar 13 2009 | DOCUSIGN, INC | Systems and methods for document management transformation and security |
| 8239668, | Apr 15 2009 | TREND MICRO INCORPORATED | Computer security threat data collection and aggregation with user privacy protection |
| 8255223, | Dec 03 2004 | Microsoft Technology Licensing, LLC | User authentication by combining speaker verification and reverse turing test |
| 8266439, | Sep 12 2007 | Hewlett Packard Enterprise Development LP | Integrity verification of pseudonymized documents |
| 8284942, | Aug 24 2004 | Microsoft Technology Licensing, LLC | Persisting private/public key pairs in password-encrypted files for transportation to local cryptographic store |
| 8307443, | Sep 28 2007 | Microsoft Technology Licensing, LLC | Securing anti-virus software with virtualization |
| 8321667, | Feb 28 2007 | Microsoft Technology Licensing, LLC | Security model for common multiplexed transactional logs |
| 8396933, | Jan 15 1999 | Digital Reg of Texas, LLC. | Delivering electronic content |
| 8402558, | Oct 20 2003 | Digital Reg of Texas, LLC | Securing digital content system and method |
| 8424102, | Aug 31 2004 | Adobe Inc | Document access auditing |
| 8429131, | Nov 17 2004 | MICRO FOCUS LLC | Systems and methods for preventing digital asset restoration |
| 8433657, | Apr 15 2011 | HUAWEI TECHNOLOGIES CO , LTD | Secure and mobile financial transaction |
| 8457974, | Dec 03 2004 | Microsoft Technology Licensing, LLC | User authentication by combining speaker verification and reverse turing test |
| 8532621, | Aug 26 2005 | Malikie Innovations Limited | Data session authentication credentials update for a wireless communication device |
| 8533122, | Apr 15 2011 | HUAWEI TECHNOLOGIES CO , LTD | Wireless payment with a portable device |
| 8544110, | Jan 27 2006 | APPRISS RETAIL INFORMATION LLC | Sensitive data aliasing |
| 8620782, | Jun 28 2001 | CheckFree Services Corporation | Inter-network electronic billing |
| 8655961, | Jul 18 2007 | DocuSign, Inc. | Systems and methods for distributed electronic signature documents |
| 8694598, | May 20 2010 | Western Digital Israel Ltd | Host device and method for accessing a virtual file in a storage device by bypassing a cache in the host device |
| 8745416, | Mar 26 2012 | CA, INC | Systems and methods for secure third-party data storage |
| 8799247, | Feb 11 2011 | VONAGE BUSINESS INC | System and methods for ensuring integrity, authenticity, indemnity, and assured provenance for untrusted, outsourced, or cloud databases |
| 8799675, | Jan 05 2012 | INDORSE SERVICES | System and method for electronic certification and authentication of data |
| 8842841, | Feb 20 2012 | KL DATA SECURITY PTY LTD | Cryptographic method and system |
| 8874480, | Apr 27 2007 | CheckFree Services Corporation | Centralized payment method and system for online and offline transactions |
| 8925108, | Aug 31 2004 | Adobe Inc | Document access auditing |
| 8930697, | Oct 20 2004 | Digital Reg of Texas, LLC | Securing digital content system and method |
| 8935186, | Apr 15 2011 | HUAWEI TECHNOLOGIES CO , LTD | Wireless payment with a portable device |
| 8943332, | Oct 31 2006 | Hewlett Packard Enterprise Development LP | Audit-log integrity using redactable signatures |
| 8949427, | Feb 25 2011 | International Business Machines Corporation | Administering medical digital images with intelligent analytic execution of workflows |
| 8949706, | Jul 18 2007 | DocuSign, Inc.; DOCUSIGN, INC | Systems and methods for distributed electronic signature documents |
| 8949708, | Jun 11 2010 | DOCUSIGN, INC | Web-based electronically signed documents |
| 8977856, | Aug 31 2012 | Malikie Innovations Limited | Methods and apparatus for use in sharing credentials amongst a plurality of mobile communication devices |
| 8984656, | Jan 27 2006 | APPRISS RETAIL INFORMATION LLC | Sensitive data aliasing |
| 9038155, | Dec 02 2011 | University of Tulsa | Auditable multiclaim security token |
| 9043587, | Apr 15 2009 | TREND MICRO INCORPORATED | Computer security threat data collection and aggregation with user privacy protection |
| 9092597, | Dec 09 2009 | Western Digital Israel Ltd | Storage device and method for using a virtual file in a public memory area to access a plurality of protected files in a private memory area |
| 9094479, | Jan 15 1999 | Digital Reg of Texas, LLC | Delivering electronic content |
| 9104985, | Aug 17 2011 | International Business Machines Corporation | Processing system using metadata for administering a business transaction |
| 9173085, | Jul 06 2012 | Malikie Innovations Limited | Methods and apparatus for use in transferring an assignment of a secure chip subscription managers |
| 9191372, | Nov 24 1998 | Digital Reg of Texas, LLC | Tracking electronic content |
| 9191376, | Oct 20 2003 | Digital Reg of Texas, LLC | Securing digital content system and method |
| 9203612, | Jun 02 2014 | Atlanta DTH, Inc. | Systems and methods for controlling media distribution |
| 9230100, | Sep 28 2007 | Microsoft Technology Licensing, LLC | Securing anti-virus software with virtualization |
| 9230130, | Mar 22 2012 | DOCUSIGN, INC | System and method for rules-based control of custody of electronic signature transactions |
| 9251131, | May 04 2010 | DocuSign, Inc. | Systems and methods for distributed electronic signature documents including version control |
| 9268758, | Jul 14 2011 | DocuSign, Inc. | Method for associating third party content with online document signing |
| 9460298, | Jan 27 2006 | APPRISS RETAIL INFORMATION LLC | Sensitive data aliasing |
| 9514117, | Feb 28 2007 | DocuSign, Inc. | System and method for document tagging templates |
| 9572016, | Jul 06 2012 | Malikie Innovations Limited | Methods and apparatus for use in transferring an assignment of a secure chip between subscription managers |
| 9628462, | Jul 14 2011 | DocuSign, Inc. | Online signature identity and verification in community |
| 9634975, | Jul 18 2007 | DocuSign, Inc. | Systems and methods for distributed electronic signature documents |
| 9659041, | Jan 30 2012 | Oracle International Corporation | Model for capturing audit trail data with reduced probability of loss of critical data |
| 9710615, | Sep 27 2007 | UNITED SERVICES AUTOMOBILE ASSOCIATION USAA | Systems and methods for secure online repositories |
| 9721101, | Jun 24 2013 | Red Hat, Inc.; Red Hat, Inc | System wide root of trust chaining via signed applications |
| 9734476, | Jul 13 2011 | International Business Machines Corporation | Dynamically allocating data processing components |
| 9779376, | Jul 13 2011 | International Business Machines Corporation | Dynamically allocating business workflows |
| 9798710, | May 04 2010 | DocuSign, Inc. | Systems and methods for distributed electronic signature documents including version control |
| 9817850, | Feb 25 2011 | International Business Machines Corporation | Auditing database access in a distributed medical computing environment |
| 9824198, | Jul 14 2011 | DOCUSIGN, INC | System and method for identity and reputation score based on transaction history |
| 9832174, | Aug 11 2015 | NetApp, Inc. | Authentication for cluster peering |
| 9836485, | Feb 25 2011 | International Business Machines Corporation | Auditing database access in a distributed medical computing environment |
| 9848009, | Nov 29 2010 | BIOCATCH LTD | Identification of computerized bots and automated cyber-attack modules |
| 9875376, | Jan 27 2006 | APPRISS RETAIL INFORMATION LLC | Sensitive data aliasing |
| 9886585, | Jun 14 2013 | SAP SE | Multi-layer data security |
| 9893895, | Mar 22 2012 | DocuSign, Inc. | System and method for rules-based control of custody of electronic signature transactions |
| 9971754, | Jul 14 2011 | DOCUSIGN, INC | Method for associating third party content with online document signing |
| RE47313, | Oct 20 2003 | Digital Reg of Texas, LLC | Securing digital content system and method |
| RE49119, | Mar 22 2012 | DocuSign, Inc. | System and method for rules-based control of custody of electronic signature transactions |
| Patent | Priority | Assignee | Title |
| 5657390, | Aug 25 1995 | Meta Platforms, Inc | Secure socket layer application program apparatus and method |
| 5978475, | Jul 18 1997 | BT AMERICAS INC | Event auditing system |
| 6088747, | Feb 20 1998 | Unisys Corporation | System for reformatting and burning of data files having a first format onto a compact disk to be utilized in a network using different format |
| 6574609, | Aug 13 1998 | Wistron Corporation | Secure electronic content management system |
| 6584466, | Apr 07 1999 | Microsoft Technology Licensing, LLC | Internet document management system and methods |
| 6587945, | Dec 28 1998 | Koninklijke Philips Electronics N V | Transmitting reviews with digital signatures |
| 6754820, | Jan 30 2001 | TecSec, Incorporated | Multiple level access system |
| 6868495, | Sep 12 1996 | RPX Corporation | One-time pad Encryption key Distribution |
| 6950867, | Jul 30 1999 | INTERTRUST TECHNOLOGIES CORP | System and method for managing transaction record delivery using an acknowledgement-monitoring process and a failure-recovery process with modifying the predefined fault condition |
| 6981141, | May 07 1998 | RPX Corporation | Transparent encryption and decryption with algorithm independent cryptographic engine that allows for containerization of encrypted files |
| 20020007453, | |||
| 20020019936, | |||
| 20020055942, | |||
| 20020133707, | |||
| 20020188638, | |||
| 20030217264, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Nov 02 2006 | NEMOVICHER, KERRY | KENEISYS CORP | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 018481 | /0276 |
| Date | Maintenance Fee Events |
| Aug 12 2009 | ASPN: Payor Number Assigned. |
| Dec 28 2011 | M2551: Payment of Maintenance Fee, 4th Yr, Small Entity. |
| Feb 12 2016 | REM: Maintenance Fee Reminder Mailed. |
| Jul 01 2016 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
| Date | Maintenance Schedule |
| Jul 01 2011 | 4 years fee payment window open |
| Jan 01 2012 | 6 months grace period start (w surcharge) |
| Jul 01 2012 | patent expiry (for year 4) |
| Jul 01 2014 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Jul 01 2015 | 8 years fee payment window open |
| Jan 01 2016 | 6 months grace period start (w surcharge) |
| Jul 01 2016 | patent expiry (for year 8) |
| Jul 01 2018 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Jul 01 2019 | 12 years fee payment window open |
| Jan 01 2020 | 6 months grace period start (w surcharge) |
| Jul 01 2020 | patent expiry (for year 12) |
| Jul 01 2022 | 2 years to revive unintentionally abandoned end. (for year 12) |