Personal access management system5694472
Abstract
A multi-component system for linking a user to a product or service provider includes a user processing device, a storage device, and a provider device. The storage device stores provider-specific application software, user-specific data, and a file management program. The storage device and the processing device are coupled to each other to form a user device which communicates with the provider device. Under direction of the file management program, the processing device carries out a recognition methodology which determines whether the processing device and the storage device are authorized to operate with each other. This aspect of the system makes it possible to render the storage device operable only with a specific user processing device, referred to as the principal processing device. This, in turn, reduces the possibility of fraud since the storage device cannot be used without the principal processing device. Once it is determined that the processing and storage devices are authorized to interact with each other, the processing device executes the provider-specific application software to exchange information with the provider device. Together, the user and provider devices implement unique recognition and comprehension methodologies to ensure that the parties are authorized to communicate with each other and to ensure that the information exchanged cannot be understood by third parties. Overall, the system provides a highly secure mechanism for transferring information from one party to another.
Claims
What is claimed is:
1. In a system having a processing device and a storage device, the storage device having a set of instructions and a file stored thereon, a method for coordinating access to said file, comprising the steps of:
accessing by the processing device said set of instructions stored on the storage device; and
executing by the processing device said set of instructions to carry out the steps of:
retrieving file access coordination parameters from both the storage device and the processing device;
processing said parameters to determine whether the processing device is authorized to access said file stored on the storage device; and
denying access to said file in response to a determination that the processing device is not authorized to access said file,
wherein the processing device further performs the steps of:
deriving a set of new file access coordination parameters; and
storing at least a subset of said new file access coordination parameters into the storage device for use in coordinating access to said file in a future session.
2. In a system having a processing device and a storage device, the storage device having a set of instructions and a file stored thereon, a method for coordinating access to said file, comprising the steps of:
accessing by the processing device said set of instructions stored on the storage device; and
executing by the processing device said set of instructions to carry out the steps of:
retrieving file access coordination parameters from both the storage device and the processing device;
processing said parameters to determine whether the processing device is authorized to access said file stored on the storage device; and
denying access to said file in response to a determination that the processing device is not authorized to access said file,
wherein the step of retrieving file access coordination parameters comprises the steps of:
retrieving an operational key file name and a file identification code from the storage device; and
retrieving a key code, using said operational key file name as an index, from the processing device.
3. The method of claim 2, wherein the step of processing said parameters comprises the steps of:
processing said file identification code using said key code to derive a processed file identification code; and
comparing said processed file identification code with a reference code stored on the storage device to determine whether the processing device is authorized to access said file.
4. The method of claim 3, wherein the step of processing said file identification code comprises the step of:
encrypting said file identification code using said key code as an encryption key.
5. In a system having a processing device and a storage device, the storage device having a set of instructions and a file stored thereon, said set of instructions having an unencrypted portion and an encrypted portion, a method for coordinating access to said file, comprising the steps of:
accessing by the processing device said unencrypted portion of said instructions;
executing by the processing device said unencrypted portion of said instructions to carry out the step of:
decrypting said encrypted portion of said instructions to derive a set of decrypted instructions; and
executing by the processing device said decrypted instructions to carry out the steps of:
retrieving file access coordination parameters from both the storage device and the processing device;
processing said parameters to determine whether the processing device is authorized to access said file stored on the storage device; and
denying access to said file in response to a determination that the processing device is not authorized to access said file.
6. The method of claim 5, wherein the processing device further performs the steps of:
deriving a set of new file access coordination parameters; and
storing at least a subset of said new file access coordination parameters into the storage device for use in coordinating access to said file in a future session.
7. The method of claim 5, wherein the step of decrypting said encrypted portion of said instructions comprises the steps of:
retrieving an operational key file name from the storage device;
retrieving, using said operational key file name as an index, a key code from the processing device; and
decrypting said encrypted portion of said instructions using said key code as a decryption key to derive said set of decrypted instructions.
8. The method of claim 5, wherein the step of retrieving file access coordination parameters comprises the steps of:
retrieving an operational key file name and a file identification code from the storage device; and
retrieving, using said operational key file name as an index, a key code from the processing device.
9. The method of claim 8, wherein the step of processing said parameters comprises the steps of:
processing said file identification code using said key code to derive a processed file identification code; and
comparing said processed file identification code with a reference code stored on the storage device to determine whether the processing device is authorized to access said file.
10. The method of claim 9, wherein the step of processing said file identification code comprises the step of:
encrypting said file identification code using said key code as an encryption key.
11. In a system having a processing device and a storage device, a method for coordinating access to a file stored on the storage device, comprising the steps of:
retrieving from the storage device an operational key file name and a file identification code;
retrieving, using said operational key file name as an index, a key code from the processing device;
processing said file identification code using said key code to derive a processed file identification code; and
comparing said processed file identification code with a reference code stored on the storage device to determine whether the processing device is authorized to access said file.
12. The method of claim 11, further comprising the step of:
denying access to said file in response to a determination that said processed file identification code is inconsistent with said reference code.
13. The method of claim 11, wherein the step of processing said file identification code comprises the step of:
encrypting said file identification code using said key code as an encryption key.
14. The method of claim 11, further comprising the steps of:
deriving a set of new file access coordination parameters; and
storing at least a subset of said new file access coordination parameters into the storage device for use in coordinating access to said file in a future session.
15. The method of claim 11, further comprising the steps of:
storing a new operational key file name onto the storage device; and
storing a new reference code onto the storage device.
16. The method of claim 15, further comprising the steps of:
retrieving from the storage device said new operational key file name and said file identification code;
retrieving, using said new operational key file name as an index, a new key code from the processing device;
processing said file identification code using said new key code to derive a new processed file identification code; and
comparing said new processed file identification code with said new reference code to determine whether the processing device is authorized to access said file.
17. The method of claim 11, further comprising the steps of:
retrieving a new operational key file name and a corresponding new key code from the processing device;
processing said file identification code using said new key code to derive a new reference code; and
storing said new operational key file name and said new reference onto the storage device for use in coordinating access to said file in a future session.
18. The method of claim 17, further comprising the steps of:
retrieving from the storage device said new operational key file name and said file identification code;
retrieving, using said new operational key file name as an index said new key code from the processing device;
processing said file identification code using said new key code to derive a new processed file identification code; and
comparing said new processed file identification code with said new reference code to determine whether the processing device is authorized to access said file.
19. In a system having a processing device and a storage device, said storage device having a file and an encrypted file access parameter table stored thereon, a method for coordinating access to said file, comprising the steps of:
decrypting said parameter table to derive a decrypted parameter table;
extracting from said decrypted parameter table an operational key file name, a file identification code, and a reference code associated with said file;
retrieving, using said operational key file name as an index, a key code from the processing device;
processing said file identification code using said key code to derive a processed file identification code; and
comparing said processed file identification code with said reference code to determine whether the processing device is authorized to access said file.
20. The method of claim 19, wherein the step of processing said file identification code comprises the step of:
encrypting said file identification code using said key code as an encryption key.
21. The method of claim 19, wherein the step of decrypting said encrypted parameter table comprises the steps of:
retrieving from the storage device a second operational key file name;
retrieving, using said second operational key file name as an index, a second key code from the processing device; and
decrypting said encrypted parameter table using said second key code as a decryption key.
22. The method of claim 19, further comprising the steps of:
storing a new operational key file name in said decrypted parameter table; and
storing a new reference code in said decrypted parameter table.
23. The method of claim 22, further comprising the steps of:
encrypting information contained in said decrypted parameter table to derive a new encrypted file access parameter table; and
storing said new encrypted parameter table onto the storage device.
24. The method of claim 19, further comprising the steps of:
retrieving a new operational key file name and a corresponding new key code from the processing device;
processing said file identification code using said new key code to derive a new reference code; and
storing said new operational key file name and said new reference code onto the storage device for use in coordinating access to said file in a future session.
25. The method of claim 24, wherein the step of storing said new operational key file name and said new reference code comprises the steps of:
storing said new operational key file name and said new reference code into said decrypted parameter table;
encrypting information contained in said decrypted parameter table to derive a new encrypted file access parameter table; and
storing said new encrypted parameter table onto the storage device.
26. In a system having a processing device and a storage device, said storage device having a processed file stored thereon, a method for extracting de-processed information from said processed file, comprising the steps of:
retrieving from the storage device an operational key file name associated with said processed file;
retrieving, using said operational key file name as an index, a key code from the processing device; and
processing said processed file using said key code to extract a set of de-processed information from said processed file.
27. The method of claim 26, wherein said processed file is an encrypted file, and wherein the step of processing said processed file comprises the step of:
decrypting said processed file using said key code as a decryption key.
28. The method of claim 26, further comprising the following steps, performed prior to the step of retrieving said operational key file name from the storage device:
determining whether the processing device is authorized to access said processed file; and
denying access to said processed file in response to a determination that the processing device is not authorized to access said processed file.
29. The method of claim 26, further comprising the steps of:
processing said de-processed information using a new key code to derive a new processed file; and
storing said new processed file onto the storage device.
30. The method of claim 26, further comprising the steps of:
retrieving a new operational key file name and a corresponding new key code from the processing device;
processing said de-processed information using said new key code to derive a new processed file; and
storing said new processed file onto the storage device.
31. The method of claim 30, further comprising the step of:
storing said new operational key file name onto the storage device.
32. The method of claim 30, wherein the step of processing said de-processed information comprises the step of:
encrypting said de-processed information using said new key code as an encryption key.
33. In a system having a processing device and a storage device, said storage device having a processed file and an encrypted parameter tabs stored thereon, a method for extracting de-processed information from said processed file, comprising the steps of:
decrypting said encrypted parameter table to derive a decrypted parameter table;
extracting from said decrypted parameter table an operational key file name associated with said processed file;
retrieving, using said operational key file name as an index, a key code from the processing device; and
processing said processed file using said key code to extract a set of de-processed information from said processed file.
34. The method of claim 33, wherein said processed file is an encrypted file, and wherein the step of processing said processed file comprises the step of:
decrypting said processed file using said key code as a decryption key.
35. The method of claim 33, wherein the step of decrypting said encrypted parameter table comprises the steps of:
retrieving from the storage device a second operational key file name;
retrieving, using said second operational key file name as an index, a second key code from the processing device; and
decrypting said encrypted parameter table using said second key code as a decryption key.
36. The method of claim 33, further comprising the steps of:
determining whether the processing device is authorized to access said processed file; and
denying access to said processed file in response to a determination that the processing device is not authorized to access said processed file.
37. The method of claim 33, further comprising the steps of:
processing said de-processed information using a new key code to derive a new processed file; and
storing said new processed file onto the storage device.
38. The method of claim 26, further comprising the steps of:
retrieving a new operational key file name and a corresponding new key code from the processing device;
processing said de-processed information using said new key code to derive a new processed file; and
storing said new processed file onto the storage device.
39. The method of claim 38, further comprising the steps of:
storing said new operational key file name into said decrypted parameter table;
encrypting information contained in said decrypted parameter table to derive a new encrypted parameter table; and
storing said new encrypted parameter table onto the storage device.
40. The method of claim 38, wherein the step of processing said de-processed information comprises the step of:
encrypting said de-processed information using said new key code as an encryption key.
41. A storage device for interacting with a processing device, said storage device comprising:
a first storage unit for storing a file;
a second storage unit for storing a first set of file access parameters;
means for causing the processing device to retrieve said first set of file access parameters;
means for causing the processing device to retrieve a second set of file access parameters from the processing device;
means for causing the processing device to process said first and second sets of file access parameters to determine whether the processing device is authorized to access said file; and
means for causing the processing device to deny access to said file in response to a determination that the processing device is not authorized to access said file.
42. A storage device for interacting with a processing device, said storage device comprising:
a first storage unit for storing a file;
a second storage unit for storing an operational key file name, a file identification code, and a reference code;
means for causing the processing device to retrieve said operational key file name and said file identification code;
means for causing the processing device to retrieve, using said operational key file name as an index, a key code from the processing device;
means for causing the processing device to process said file identification code using said key code to derive a processed file identification code; and
means for causing the processing device to compare said processed file identification code with said reference code to determine whether the processing device is authorized to access said file.
43. The storage device of claim 42, further comprising:
means for causing the processing device to derive a set of new file access parameters; and
means for causing the processing device to store at least a subset of said new file access parameters into said second storage unit for use in coordinating access to said file in a future session.
44. The storage device of claim 42, further comprising:
means for causing the processing device to store a new operational key file name into said second storage unit; and
means for causing the processing device to store a new reference code into said second storage unit.
45. The storage device of claim 42, further comprising:
means for causing the processing device to retrieve a new operational key file name and a corresponding new key code from the processing device;
means for causing the processing device to process said file identification code using said new key code to derive a new reference code; and
means for causing the processing device to store said new operational key file name and said new reference code into said second storage unit for use in coordinating access to said file in a future session.
46. A storage device for interacting with a processing device, said storage device having a file and an encrypted file access parameter table stored thereon, said storage device comprising:
means for causing the processing device to decrypt said encrypted parameter table to derive a decrypted parameter table;
means for causing the processing device to extract from said decrypted parameter table an operational key file name, a file identification code, and a reference code associated with said file;
means for causing the processing device to retrieve, using said operational key file name as an index, a key code from the processing device;
means for causing the processing device to process said file identification code using said key code to derive a processed file identification code; and
means for causing the processing device to compare said processed file identification code with said reference code to determine whether the processing device is authorized to access said file.
47. The storage device of claim 46, further comprising:
means for causing the processing device to derive a set of new file access parameters;
means for causing the processing device to store at least a subset of said new file access parameters into said decrypted parameter table;
means for causing the processing device to encrypt information contained in said decrypted parameter table to derive a new encrypted parameter table; and
means for causing the processing device to store said new encrypted parameter table into said second storage unit.
48. The storage device of claim 46, further comprising:
means for causing the processing device to store a new operational key file name and a new reference code into said decrypted parameter table;
means for causing the processing device to encrypt information contained in said decrypted parameter table to derive a new encrypted parameter table; and
means for causing the processing device to store said new encrypted parameter table into said second storage unit.
49. The storage device of claim 46, further comprising:
means for causing the processing device to retrieve a new operational key file name and a corresponding new key code from the processing device;
means for causing the processing device to process said file identification code using said new key code to derive a new reference code; and
means for causing the processing device to store said new operational key file name and said new reference code into said second storage unit for use in coordinating access to said file in a future session.
50. The storage device of claim 46, further comprising:
means for causing the processing device to retrieve a new operational key file name and a corresponding new key code from the processing device;
means for causing the processing device to process said file identification code using said new key code to derive a new reference code;
means for causing the processing device to store said new operational key file name and said new reference code into said decrypted parameter table;
means for causing the processing device to encrypt information contained in said decrypted parameter table to derive a new encrypted parameter table; and
means for causing the processing device to store said new encrypted parameter table into said second storage unit.
51. A storage device for interacting with a processing device, said storage device comprising:
a first storage unit for storing a processed file;
a second storage unit for storing an operational key file name associated with said processed file;
means for causing the processing device to retrieve said operational key file name;
means for causing the processing device to retrieve, using said operational key file name as an index, a key code from the processing device; and
means for causing the processing device to process said processed file using said key code to extract a set of de-processed information from said processed file.
52. The storage device of claim 51, further comprising:
means for causing the processing device to determine whether the processing device is authorized to access said processed file; and
means for causing the processing device to deny access to said processed file in response to a determination that the processing device is not authorized to access said processed file.
53. The storage device of claim 51, further comprising:
means for causing the processing device to process said de-processed information using a new key code to derive a new processed file; and
means for causing the processing device to store said new processed file into said first storage unit.
54. The storage device of claim 51, further comprising:
means for causing the processing device to retrieve a new operational key file name and a corresponding new key code from the processing device;
means for causing the processing device to process said de-processed information using said new key code to derive a new processed file; and
means for causing the processing device to store said new processed file into said first storage unit.
55. The storage device of claim 54, further comprising:
means for causing the processing device to store said new operational key file name into said second storage unit.
56. A storage device for interacting with a processing device, said storage device comprising:
a first storage unit for storing a processed file;
a second storage unit for storing an encrypted parameter table;
means for causing the processing device to decrypt said encrypted parameter table to derive a decrypted parameter table;
means for causing the processing device to extract from said decrypted parameter table an operational key file name associated with said processed file;
means for causing the processing device to retrieve, using said operational key file name as an index, a key code from the processing device; and
means for causing the processing device to process said processed file using said key code to extract a set of de-processed information from said processed file.
57. The storage device of claim 56, further comprising:
means for causing the processing device to determine whether the processing device is authorized to access said processed file; and
means for causing the processing device to deny access to said processed file in response to a determination that the processing device is not authorized to access said processed file.
58. The storage device of claim 56, further comprising:
means for causing the processing device to process said de-processed information using a new key code to derive a new processed file; and
means for causing the processing device to store said new processed file into said first storage unit.
59. The storage device of claim 56, further comprising:
means for causing the processing device to retrieve a new operational key file name and a corresponding new key code from the processing device;
means for causing the processing device to process said de-processed information using said new key code to derive a new processed file; and
means for causing the processing device to store said new processed file into said first storage unit.
60. The storage device of claim 59, further comprising:
means for causing the processing device to store said new operational key file name into said decrypted parameter table;
means for causing the processing device to encrypt information contained in said decrypted parameter table to derive a new encrypted parameter table; and
means for causing the processing device to store said new encrypted parameter table into said second storage unit.
61. A processing assembly, comprising:
a processing device comprising a processor, a memory coupled to said processor having a first set of file access parameters stored therein, and a storage device interface coupled to said processor for receiving one of a number of storage devices; and
a storage device for coupling to said storage device interface, said storage device comprising:
a first storage unit for storing a file;
a second storage unit for storing a second set of file access parameters;
means for causing said processor to retrieve said first and second sets of file access parameters;
means for causing said processor to process said first and second sets of file access parameters to determine whether said processing device is authorized to access said file; and
means for causing said processor to deny access to said file in response to a determination that said processing device is not authorized to access said file.
62. A processing assembly, comprising:
a processing device comprising a processor, a memory coupled to said processor having a a plurality of file access parameters stored therein, and a storage device interface coupled to said processor for receiving one of a number of storage devices; and
a storage device for coupling to said storage device interface, said storage device comprising:
a first storage unit for storing a file;
a second storage unit for storing an operational key file name, a file identification code, and a reference code;
means for causing said processor to retrieve said operational key file name and said file identification code;
means for causing said processor to retrieve, using said operational key file name as an index, a key code from said memory;
means for causing said processor to process said file identification code using said key code to derive a processed the identification code; and
means for causing said processor to compare said processed file identification code with said reference code to determine whether said processing device is authorized to access said file.
63. The processing assembly of claim 62, wherein said storage device further comprises:
means for causing said processor to derive a set of new file access parameters; and
means for causing said processor to store at least a subset of said new file access parameters into said second storage unit for use in coordinating access to said file in a future session.
64. The processing assembly of claim 62, wherein said storage device further comprises:
means for causing said processor to store a new operational key file name into said second storage unit; and
means for causing said processor to store a new reference code into said second storage unit.
65. The processing assembly of claim 62, wherein said storage device further comprises:
means for causing said processor to retrieve a new operational key file name and a corresponding new key code from said memory;
means for causing said processor to process said file identification code using said new key code to derive a new reference code; and
means for causing said processor to store said new operational key file name and said new reference code into said second storage unit for use in coordinating access to said file in a future session.
66. A processing assembly, comprising:
a processing device comprising a processor, a memory coupled to said processor having a a plurality of file access parameters stored therein, and a storage device interface coupled to said processor for receiving one of a number of storage devices; and
a storage device for coupling to said storage device interface, said storage device comprising:
a first storage unit for storing a file;
a second storage unit for storing an encrypted file access parameter table;
means for causing said processor to decrypt said encrypted parameter table to derive a decrypted parameter table;
means for causing said processor to extract from said decrypted parameter table an operational key file name, a file identification code, and a reference code associated with said file;
means for causing said processor to retrieve, using said operational key file name as an index, a key code from said memory;
means for causing said processor to process said file identification code using said key code to derive a processed file identification code; and
means for causing said processor to compare said processed file identification code with said reference code to determine whether said processing device is authorized to access said file.
67. The processing assembly of claim 66, wherein said storage device further comprises:
means for causing said processor to derive a set of new file access parameters;
means for causing said processor to store at least a subset of said new file access parameters into said decrypted parameter table;
means for causing said processor to encrypt information contained in said decrypted parameter table to derive a new encrypted parameter table; and
means for causing said processor to store said new encrypted parameter table into said second storage unit.
68. The processing assembly of claim 66, wherein said storage device further comprises:
means for causing said processor to store a new operational key file name and a new reference code into said decrypted parameter table;
means for causing said processor to encrypt information contained in said decrypted parameter table to derive a new encrypted parameter table; and
means for causing said processor to store said new encrypted parameter table into said second storage unit.
69. The processing assembly of claim 66, wherein said storage device further comprises:
means for causing said processor to retrieve a new operational key file name and a corresponding new key code from said memory;
means for causing said processor to process said file identification code using said new key code to derive a new reference code; and
means for causing said processor to store said new operational key file name and said new reference code into said second storage unit for use in coordinating access to said file in a future session.
70. The processing assembly of claim 66, wherein said storage device further comprises:
means for causing said processor to retrieve a new operational key file name and a corresponding new key code from said memory;
means for causing said processor to process said file identification code using said new key code to derive a new reference code;
means for causing said processor to store said new operational key file name and said new reference code into said decrypted parameter table;
means for causing said processor to encrypt information contained in said decrypted parameter table to derive a new encrypted parameter table; and
means for causing said processor to store said new encrypted parameter table into said second storage unit.
71. A processing assembly, comprising:
a processing device comprising a processor, a memory coupled to said processor having a a plurality of file access parameters stored therein, and a storage device interface coupled to said processor for receiving one of a number of storage devices; and
a storage device for coupling to said storage device interface, said storage device comprising:
a first storage unit for storing a processed file;
a second storage unit for storing an operational key file name associated with said processed file;
means for causing said processor to retrieve said operational key file name;
means for causing said processor to retrieve, using said operational key file name as an index, a key code from said memory; and
means for causing said processor to process said processed file using said key code to extract a set of de-processed information from said processed file.
72. The processing assembly of claim 71, wherein said storage device further comprises:
means for causing said processor to determine whether said processing device is authorized to access said processed file; and
means for causing said processor to deny access to said processed file in response to a determination that said processing device is not authorized to access said processed file.
73. The processing assembly of claim 71, wherein said storage device further comprises:
means for causing said processor to process said de-processed information using a new key code to derive a new processed file; and
means for causing said processor to store said new processed file into said first storage unit.
74. The processing assembly of claim 71, wherein said storage device further comprises:
means for causing said processor to retrieve a new operational key file name and a corresponding new key code from said memory;
means for causing said processor to process said de-processed information using said new key code to derive a new processed file; and
means for causing said processor to store said new processed file into said first storage unit.
75. The processing assembly of claim 74, wherein said storage device further comprises:
means for causing said processor to store said new operational key file name into said second storage unit.
76. A processing assembly, comprising:
a processing device comprising a processor, a memory coupled to said processor having a a plurality of file access parameters stored therein, and a storage device interface coupled to said processor for receiving one of a number of storage devices; and
a storage device for coupling to said storage device interface, said storage device comprising:
a first storage unit for storing a processed file;
a second storage unit for storing an encrypted parameter table;
means for causing said processor to decrypt said encrypted parameter table to derive a decrypted parameter table;
means for causing said processor to extract from said decrypted parameter table an operational key file name associated with said processed file;
means for causing said processor to retrieve, using said operational key file name as an index, a key code from said memory; and
means for causing said processor to process said processed file using said key code to extract a set of de-processed information from said processed file.
77. The processing assembly of claim 76, wherein said storage device further comprises:
means for causing said processor to determine whether said processing device is authorized to access said processed file; and
means for causing said processor to deny access to said processed file in response to a determination that said processing device is not authorized to access said processed file.
78. The processing assembly of claim 76, wherein said storage device further comprises:
means for causing said processor to process said de-processed information using a new key code to derive a new processed file; and
means for causing said processor to store said new processed file into said first storage unit.
79. The processing assembly of claim 76, wherein said storage device further comprises:
means for causing said processor to retrieve a new operational key file name and a corresponding new key code from said memory;
means for causing said processor to process said de-processed information using said new key code to derive a new processed file; and
means for causing said processor to store said new processed file into said first storage unit.
80. The processing assembly of claim 79, wherein said storage device further comprises:
means for causing said processor to store said new operational key file name into said decrypted parameter table;
means for causing said processor to encrypt information contained in said decrypted parameter table to derive a new encrypted parameter table; and
means for causing said processor to store said new encrypted parameter table into said second storage unit.
Description
FIELD OF THE INVENTION
This invention relates generally to transactional, communication, and authorization systems, and more particularly to a multi-component system which implements unique recognition and comprehension methodologies to verify party identities and to ensure session security.
BACKGROUND OF THE INVENTION
For a number of years now, tremendous efforts have been devoted to devising systems for linking consumers with product and service providers which would allow the consumers to communicate and to transact with the providers from remote locations, such as from their homes. Such efforts have produced some systems which have received a small degree of acceptance. Examples include home shopping networks (such as QVC), home entertainment systems (such as DirecTV), remote stock transaction systems (such as Reuters), and automatic teller machine (ATM) systems. While these remote systems have gained some acceptance, there still is, for the most part, an absence of a generally and widely accepted system for conducting business from a remote site.
The failure of the presently existing systems can be attributed to a number of different factors. One possible factor is cost, both in terms of the providers' cost and the cost to the consumers. Currently, consumers are typically linked to providers not directly but through aggregators. The presence of an aggregator adds a middleman to the business process which in turn increases the cost to the consumers. High cost is a reason that many consumers hesitate to buy products through an electronic system. The reason that aggregators are necessary is that the linking systems currently used consist of complex, proprietary equipment which are expensive to operate and to maintain. The high cost of such a system presents a formidable barrier to providers who wish to link themselves directly to consumers.
Another possible factor for the failure of the existing systems is the lack of an overall standard system which can be applied generally to a number of different applications. The existing linking systems are, for the most part, application-specific systems. That is, each system is specifically designed to carry out a particular purpose. Typically, proprietary methodologies are implemented and proprietary equipment is used. Application-specific systems are usually effective for their intended purposes; however, they do have a significant practical drawback in that they tend to proliferate the use of a large number of different methods and systems. The problem with the proliferation of a myriad of methods and systems is that they force consumers to buy different equipment for each application, and to learn to use a different system for each application. This makes it very expensive for a consumer to be linked to a large number of providers, and it also imposes a heavy time burden on the consumer. Many consumers are unwilling to invest the money or the time needed to take advantage of the existing proprietary linking systems. A more general system, usable in a variety of different applications, would be more readily accepted.
High cost and the lack of a generally applicable system are factors which have contributed to the failure of the existing linking systems, but probably the most important factor is that of security. Many people inherently distrust machines and, hence, are reluctant to conduct important matters by way of machines in the first place. This distrust is only exacerbated by reports of fraud being perpetrated on electronic systems. In order to be successful, a linking system needs to ensure that user transactions and communications will be secure. This involves both verifying that the proper parties are conducting the transaction, and ensuring that information transferred between the parties cannot be intercepted and used fraudulently by third parties. Thus far, no generally applicable system which is cost effective and convenient to use performs this function satisfactorily. Hence, there exists a need for an improved system for linking users to providers.
SUMMARY OF THE INVENTION
In accordance with the present invention, there is provided a multi-component system, comprising a processing device, a storage device, and a provider device, which implements unique recognition and comprehension methodologies to ensure that transactions conducted from remote locations are secure. In the system of the present invention, the processing device and the storage device couple to each other to form an overall user device, and once formed, this user device establishes a link with the provider device to communicate with a particular provider or a particular group of providers. In the preferred embodiment, the processing device provides the processing and communication capabilities, while the storage device provides the instructions necessary for communicating with a specific provider device. Preferably, the processing device executes the instructions stored on the storage device to communicate with the specific provider. In the system of the present invention, to communicate with another provider, all a user needs to do is to couple another storage device to the same processing device, and to instruct the processing device to execute the provider-specific instructions stored on that new storage device. This aspect of the present invention allows it to be generally applied to a number of different applications involving a number of different providers.
To ensure party recognition, a recognition methodology is preferably implemented both between the processing device and the storage device, and between the user device and the provider device. Consequently, only the proper devices may be coupled together to form a user device, and only a valid user device may communicate with the provider device. To ensure information security, data stored on the storage device is encrypted, and information transferred between the user and provider devices is also encrypted. Thus, even if a storage device is lost, or information sent between the user device and the provider device is intercepted, no comprehensible information can be derived therefrom. As an extra measure of security, the parameters used to effect the recognition and encryption methodologies are preferably dynamically and regularly updated. By so doing, even if a third party is able to fraudulently obtain the parameters needed to "break in" to the system, that information is rendered useful only for a short period of time. Once the parameters are changed, the stolen information is useless. Thus, updating the parameters serves to minimize the damage caused by system breaches. Overall, the system of the present invention provides a highly secure mechanism for linking users to providers.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram providing a broad overview of the system 10 of the present invention.
FIG. 2a is a detailed block diagram of a first preferred embodiment of the processing device (UAS) 12 of the present invention.
FIG. 2b is a detailed block diagram of an alternative embodiment of the UAS 12 of the present invention.
FIG. 3 is a block diagram of the master EKE 70 which interfaces with the processing device 12 to establish certain parameters.
FIG. 4a is an operational flow diagram for the master EKE control program 72 stored on the master EKE 70.
FIG. 4b is a detailed flow diagram of the initialization step 804 of FIG. 4a.
FIG. 4c is a detailed flow diagram of the UAS restoration step 860 of FIG. 4a.
FIG. 4d is a detailed flow diagram of the master EKE restoration step 912 of FIG. 4a.
FIG. 4e is a detailed flow diagram of the DPIN modification step 948 of FIG. 4a.
FIG. 4f is an operational flow diagram for the decryption logic stored in section 62 of the non-volatile memory 38 of the UAS 12.
FIG. 5a depicts the manner in which the recognition and comprehension parameters (the operational key file names and the corresponding operational key codes) are organized and stored in RAM 40 of the UAS 12.
FIG. 5b depicts the manner in which the recognition and comprehension parameters are organized and stored in RAM 40 of the UAS 12 after a regular EKE 14 has been initialized.
FIG. 6 is a detailed block diagram of the storage device (EKE) 14 of the present invention illustrating the programs 140, 141, 172 and the data files 148-170 stored on the EKE 14.
FIGS. 7a is an overall operational flow diagram for the UAS-EKE control portion 142 of the PFM 140.
FIG. 7b is a detailed flow diagram of the initialization step 182 of FIG. 7a.
FIG. 7c is a detailed flow diagram of the recognition methodology step 186 of FIG. 7a.
FIG. 7d is a detailed flow diagram of the file management step 192 of FIG. 7a.
FIG. 7e is a detailed flow diagram of the recognition parameter update step 204 of FIG. 7a.
FIG. 7f is a detailed flow diagram of the file management parameter update step 206 of FIG. 7a.
FIG. 8a shows a file management table 370 which is maintained in file 152 of EKE 14 for use in coordinating access to the managed files 154-164, 170.
FIG. 8b shows the possible contents of table 370 after the EKE 14 is initialized with file management parameters.
FIG. 8c shows the possible contents of table 370 after the file management parameters have been updated.
FIG. 9a shows the contents of the RAM 40 after the PFM 140 on the EKE 14 has been decrypted.
FIG. 9b shows the contents of the RAM 40 after step 192 of FIG. 7a has been performed.
FIG. 10 is a block diagram representation of the PAS 18 of the present invention.
FIG. 11 is an operational flow diagram for a first preferred embodiment of the user device-PAS interaction control portion 144 of the PFM 140.
FIG. 12 is an operational flow diagram for a first preferred embodiment of the recognition and comprehension control program 408 of the PAS 18.
FIG. 13 is an operational flow diagram for a second preferred embodiment of the user device-PAS interaction control portion 144 of the PFM 140.
FIG. 14 is an operational flow diagram for a second preferred embodiment of the recognition and comprehension control program 408 of the PAS 18.
FIG. 15 is a block diagram representation of a paging system 1300 having the present invention incorporated therein.
FIG. 16 is a block diagram representation of an electronic polling system 1320 having the present invention incorporated therein.
FIG. 17 is a block diagram representation of an electronic banking system 1340 having the present invention incorporated therein.
FIG. 18 is a block diagram representation of an electronic authorization system 1360 having the present invention incorporated therein.
FIG. 19 is a block diagram representation of an authorizational system 1370, having the present invention incorporated therein, for controlling the operation of an automobile.
FIG. 20 is a block diagram representation of a system 1400 wherein a PAS 1402, 1404 having a user device emulation module 1406, 1408 incorporated therein, communicates directly with another PAS.
FIG. 21 is a block diagram representation of a system 1420 wherein a user device 1422, 1424 having a PAS emulation module 1430, 1436 incorporated therein, communicates directly with another user device.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
A broad overview of the system 10 of the present invention is shown in FIG. 1, wherein the system 10 preferably comprises a processing device 12, a storage device 14, and a provider device 18. Storage device 14 preferably couples to processing device 12 to form a single user device 16 which communicates with the provider device 18 via a communications link. In system 10, device 12 provides the processing capability, the communications interface needed to communicate with the provider device 18, and the user interface necessary for interfacing with a user. Device 12, however, contains a minimum of software instructions. Hence, on its own, device 12 is incapable of communicating or transacting with the provider device 18. In the preferred embodiment, device 12 is a general purpose processing device capable of carrying out any desired function so long as the proper instructions are provided.
It is storage device 14 which provides the specific program instructions and data needed by processing device 12 to operate and to interact with the provider device 18. Storage device 14 preferably contains therein: (1) a management program which controls interaction between the processing device 12 and the storage device 14, and interaction between the user device 16 and the provider device 18; (2) a provider-specific program which generates the messages (referred to herein as session codes) to be sent to the provider device 18; and (3) user-specific data which is used and manipulated by the two programs. Processing device 12 preferably accesses and executes the instructions stored on the storage device 14 once the storage device 14 is coupled thereto. In system 10, storage device 14 may take on a number of different forms including magnetic media (e.g. hard and floppy disks, magnetic stripe cards, etc.), optical media (e.g. CD-ROM), and semiconductor memory (e.g. RAM, PROM, flash memory, etc.). Any form is acceptable so long as it is capable of storing instructions and data, and can interface with the processing device 12.
As mentioned above, processing device 12 is a general purpose processing device, and as such, it is capable of interacting with and executing instructions from a number of different storage devices. A practical consequence of this is that the same processing device may be used to communicate with a number of different providers. All the user has to do to communicate with a different provider is to couple a different storage device 14 to the processing device 12. This aspect of the invention is advantageous because it significantly limits the cost to the user of implementing system 10. A user need invest in only one processing device. Thereafter, only the storage devices need to be supplemented, replaced and updated. Since it is contemplated that providers will provide storage devices to users at little or no cost, the cost to the user of communicating directly with a provider will be kept to a minimum. This aspect of the invention makes it much more practicable than most, if not all, of the prior art systems.
The provider device 18 of system 10 acts as a gateway between a user device 16 and a particular provider or a particular group of providers. Before a user device 16 can access the services and products of the provider, it must first satisfy the requirements of the provider device 18. Device 18 preferably implements a recognition methodology to ensure that the user device 16 is a valid device, and preferably implements a comprehension methodology to decipher messages from the user device into a form that the provider can understand. Once the message is deciphered, the provider device 18 may process the message itself, or it may relay the message on to a separate provider processing device which actually performs the processing function. Whether the message is processed or relayed by device 18 is a matter of design choice.
Whenever business is conducted from a remote location, i.e. in a non face-to-face setting, there is always concern over the possibility of fraud. In a system such as system 10, there are at least three major concerns: (1) the possibility of loss or theft of the storage device 14; (2) the possibility that improper parties are communicating; and (3) the possibility that third parties will intercept and use the information transferred between user device 16 and provider device 18. The system 10 of the present invention addresses and provides a solution to all of these concerns.
With regard to the possibility of loss or theft of the storage device 14, the management program stored on the storage device 14 forestalls the use of the lost or stolen device by an improper user. To elaborate, when storage device 14 is coupled to processing device 12, the processing device 12 executes the management program stored on the storage device 14 to carry out a recognition methodology whereby it is determined whether the processing device 12 and the storage device 14 are authorized to interact with each other. The recognition methodology (described in detail in a later section) is preferably carried out by processing and comparing selected sets of recognition data stored in the storage device 14 with recognition data stored in the processing device 12. Only if the two sets of recognition data are consistent will interaction between the devices 12, 14 be allowed to continue.
An important point to note here is that when a storage device is used with a processing device 12 for the first time, the management program stores customized recognition data in both the storage device and the processing device. This customized recognition data establishes a unique relationship between the storage device and the processing device 12 that cannot be established between the storage device and any other processing device (except in the highly unlikely event that another processing device has the same customized recognition data stored therein). As a consequence, once customized recognition data is established between a processing device and a storage device, the storage device is rendered inoperable with any other processing device. Hence, in system 10, if a user loses the storage device 14, system security is not compromised because the finder of the storage device cannot use the storage device with his own processing device. This aspect of the present invention greatly enhances system security. At this point, it should be noted that while a storage device establishes a unique relationship with preferably only one processing device, a processing device can establish a unique relationship with more than one storage device. This allows a single processing device to be used with a plurality of different storage devices.
System 10 also serves to ensure that only proper parties are allowed to communicate with each other. The function of party recognition and verification is carried out by both the user device 16 and the provider device 18. In communicating with the provider device 18, processing device 12 executes both the management program and the provider-specific program stored in storage device 14. These two programs cause the processing device 12 to: (1) retrieve selected recognition parameters from the storage device 14 which are unique to the device 14; (2) generate session codes to send to the provider device 18; (3) process the parameters and the session codes; and (4) send the processed parameters and processed session codes to the provider device 18. In response, provider device 18 processes the information received from the user device 16 and determines whether the user device is a valid device, i.e. is a recognized device. Access to the provider is granted only if the user device 16 is a recognized device. In addition to performing the recognition function, the provider device 18 also preferably coordinates the dynamic and regular alteration of the recognition parameters. Regularly changing the recognition parameters is desirable because it renders any fraudulently obtained information useful for only a short period of time. In system 10, the combination of implementing a recognition methodology and dynamically altering the recognition parameters makes it extremely difficult for a non-valid device to gain access to the provider. Thus, system 10 virtually assures that only the proper parties are allowed to communicate with each other.
Furthermore, the system 10 of the present invention provides a measure for shielding information transmitted between the user device 16 and the provider device 18 from third parties. Whenever information is sent from one device to another, the information is preferably encrypted. In addition, the encryption keys used in the encryption/decryption process are preferably regularly updated. Sending information in this manner makes it virtually impossible for a third party to derive any useful information from the information transmissions. Hence, session security is virtually guaranteed.
As shown by the above discussion, the system 10 of the present invention addresses and overcomes the three major security problems typically encountered in communications systems. Overall, a highly secure communications system is provided by the present invention. With this background information in mind, the invention will now be described in detail with reference to specific embodiments. In the following sections, system 10 will be referred to as the personal access management system (PAMS), processing device 12 will be designated as the user access system (UAS), storage device 14 will be referred to as the electronic key executive (EKE), and provider device 18 will be designated as the provider access system (PAS).
UAS
With reference to FIG. 2a, there is shown a detailed block diagram of a first preferred embodiment of the UAS 12 of the present invention, wherein the UAS 12 preferably comprises a general purpose processor 30 (such as an 80186 microprocessor manufactured by Intel Corporation), a storage device interface 32, a communications interface 34, a user interface 36, a non-volatile memory 38, and a random access memory (RAM) 40. In the preferred embodiment, UAS 12 takes the form of a hand-held, portable computing device; however, it should be noted that if so desired, UAS 12 may take on various other forms such as a desktop, laptop, or notebook computer, or some other form. UAS 12 is preferably a general purpose processing device. As such, it stores a minimum of its own program instructions. Preferably, processor 30 carries out desired functions by executing program instructions stored on external storage devices. Interface 32 enables the processor 30 to execute instructions stored on external devices by receiving one of a number of different storage devices, and coupling the storage device to the processor 30. Interface 32 may take on a number of different forms, but in the preferred embodiment, interface 32 is a PCMCIA port for receiving a PCMCIA compatible storage device, such as a PCMCIA memory card.
A major function of UAS 12 is to allow a user to communicate with a provider from a remote location. Consequently, UAS 12 preferably comprises a communications interface 34 for forming a communications link with the provider. Preferably, interface 34 comprises a modem 41 (such as a XE1414VS2 interface manufactured by Xecom), and a plurality of communications ports 42-46 coupled thereto. The communications ports preferably include telephone port 42 for connecting to a universal telephone network, and an analog 44 and a digital I/O port 46 for communicating by RF, optical, or cable means. These various ports give a user a good degree of flexibility in choosing the type of communications link to form with a provider. Also included in interface 34 is a computer port 48. Port 48 allows UAS 12 to readily link with a standard computer to receive information therefrom and to download information thereto.
UAS 12 also comprises a user interface 36 for communicating with a user. Interface 36 preferably comprises a display subsystem 50 for sending information to the user, and a keyboard subsystem 52 for receiving input from the user.
UAS 12 preferably further comprises memory for storing information, including a non-volatile memory 38 for storing information permanently in the UAS 12, and a RAM 40 for temporarily storing current program instructions and associated data. Several sets of instructions and data are preferably stored in the non-volatile memory 38. First, all drivers 54 which are needed to operate the components of the UAS 12, such as the display and keyboard drivers, are stored in file 54.
Also, data encryption modules 56 are stored in memory 38. These modules 56, when executed by processor 30, are capable of performing two major functions. First, they encrypt and decrypt data according to a selected algorithm. The encryption algorithms implemented by modules 56 may include DES, SKIPJACK, and various other algorithms. To maintain an open architecture, modules 56 preferably implement encryption algorithms which are industry accepted standards; however, if so desired, modules 56 may implement proprietary algorithms to limit UAS compatibility. A second function performed by modules 56 is that of generating random numbers. As will become clear, this aspect of the modules 56 is very useful in the process of dynamically altering recognition and comprehension parameters. In the UAS 12 shown in FIG. 2a, the encryption/decryption function is performed by having processor 30 execute the encryption modules 56 stored in the non-volatile memory 38. It should be noted, however, that the encryption/decryption function can be achieved in various other ways. For example, a hardware encryption component (not shown) may be coupled to and called upon by the processor 30 to carry out the encryption function. Also, an encryption processor may be incorporated into the processor 30 itself to perform the necessary encryption functions. These and other embodiments are within the contemplation of the present invention.
Non-volatile memory 38 further stores communications modules 58 for controlling the sending and receiving of information. Whenever information is sent via a communications link, certain protocols need to be observed. Modules 58, when executed by processor 30, ensure that outgoing messages are packaged and transmitted using the proper protocol, and that incoming messages are deciphered using the proper protocol. Non-volatile memory 38 further contains a section 60 for storing encrypted recognition and comprehension parameters. When a UAS 12 is new, this section 60 will not contain any data, but once the UAS 12 is initialized, encrypted recognition and comprehension parameters will be stored in section 60. As will be explained later, the parameters stored in section 60 are manipulated by processor 30 in implementing the recognition and comprehension methodologies of the present invention.
Finally, non-volatile memory 38 preferably stores dynamic personal identification number (DPIN) logic and data 62. Section 62 initially preferably stores a UAS identification code which is unique to the UAS 12, hash code generation logic, and decryption logic. After the UAS 12 is initialized, section 62 will also store a master key code and a master hash code. As will be explained in a later section, the hash code generation logic in section 62 will be executed by processor 30 to aid in generating two different key codes given a single DPIN, and the decryption logic in section 62 will be executed by processor 30 to render the information in section 60 comprehensible and useful in actual operation. Preferably, both the key generation and the decryption logic in section 62 are executed by processor 30 each time the UAS 12 is powered up.
Distributed UAS
Thus far, the UAS 12 has been described as a single dedicated device comprising all of the necessary components. As an alternative embodiment the UAS 12 may take on a distributed form wherein the components of the UAS 12 are separated into multiple component blocks. An example of such an embodiment is shown in FIG. 2b, wherein the UAS 12 is divided into two component blocks: (1) a standard hardware block 80 comprising the processing, communication, and interfacing components (hardware block 80 may be, for example, a standard personal computer having two PCMCIA ports); and (2) a software block, stored on a storage device 82, comprising the control programs and the data which render the UAS 12 unique. Preferably, storage device 82 takes the form of a PCMCIA compatible memory card. To form the overall UAS 12, the storage device 82 is simply coupled to the hardware block 80 via one of the storage device interfaces 86, 88.
In the distributed UAS embodiment shown in FIG. 2b, the hardware block 80 preferably comprises a standard, general purpose processor 84, and a plurality of components coupled thereto. These components include two storage device interfaces 86, 88, a communications interface 90, a user interface 92, and a RAM 94. Components 84-94 are preferably analogous to the corresponding components 30-36, 40 shown in FIG. 2a. Thus, these components need not be described again here. With regard to the software block 82, a plurality of control programs and data are preferably stored therein. Specifically, block 82 comprises encryption modules 100, communications module 102, encrypted recognition and comprehension parameters 104, and DPIN logic and data 106. Elements 100-106 are analogous to elements 56-62 shown in FIG. 2a; thus, they need not be re-described here.
For the most part, the two embodiments of the UAS 12 are quite similar. One notable difference, though, is the presence of the integration utility 108 in the distributed embodiment. In the distributed embodiment, one of the issues that needs to be addressed is how to make the two portions 80, 82 function as a unit. More specifically, there needs to be a mechanism for linking the software block 82 to the hardware block 80 so that the processor 84 in the hardware block 80 will know how to access and manipulate the programs and data stored in the software block 82. In the preferred embodiment shown in FIG. 2b, the integration utility 108 provides this linking mechanism. Preferably, when the storage device 82 is coupled to the hardware block 80 via the interface 86, the user directs the processor 84 to execute the integration utility 108 stored on the storage device 82. Under control of utility 108, processor 84 will set up certain procedures for accessing the programs and data stored on the storage device 82. Thereafter, the processor 84 will know how and when to access and to execute the elements 100-106 in the software block 82. Thus, the two separate blocks 80, 82 are transformed into a single working UAS. The specific structure of the integration utility 108 will vary depending upon the particular type of hardware block to which the storage device 82 is to be coupled. Thus, the integration utility is application-specific. Once formed, the distributed UAS 12 (FIG. 2b) will operate in the same manner as the integrated UAS (FIG. 2a). Namely, the distributed UAS 12 will accept a second storage device via interface 88 and will interact therewith.
The distributed embodiment of the UAS 12 shown in FIG. 2b is quite advantageous in that it is very versatile and convenient to use. As mentioned above, the hardware block 80 which forms a part of the distributed UAS 12 may be a typical personal computer having two PCMCIA ports. This means that any compatible personal computer can be transformed into a UAS by inserting the storage device 82 into one of the PCMCIA ports. This in turn means that with the distributed embodiment, a user need not carry a UAS with him, but instead may simply carry the storage device 82. Whenever he needs the use of a UAS, he simply inserts the storage device 82 into a compatible personal computer and a UAS is thereby created. A drawback of the distributed architecture, though, is that the storage device 82, because it is smaller, is easier to lose than the dedicated UAS shown in FIG. 2a. Thus, there is a slightly higher risk of a security breach. Which embodiment should be used in any particular application depends on the needs of the application. Both embodiments are effective for their intended purposes.
Initialization of the UAS Using a Master EKE
Regardless of which embodiment is used, a UAS 12 by itself is incapable of communicating with a provider. Only when a UAS 12 is coupled to a proper storage device 14 will an overall user device 16 be formed which can interact with the PAS 18. Before a UAS 12 can interact with any storage device, however, it first needs to be initialized. Initialization is preferably achieved by way of a master EKE 70 (FIG. 3), which in the preferred embodiment, takes the form of a PCMCIA memory card having a PCMCIA interface (not shown) which interfaces with the UAS 12 through interface 32 (FIG. 2a) or interface 88 (FIG. 2b). The master EKE 70 preferably contains a master EKE control program 72 which is accessed and executed by processor 30 to carry out the initialization process. An operational flow diagram for the control program 72 is shown in FIG. 4a. As noted above, the distributed and integrated UAS embodiments (shown in FIGS. 2a and 2b) operate in the same manner. Thus, for the sake of simplicity, the initialization process will be described with reference only to the integrated UAS 12 (FIG. 2a). It should be understood, though, that the distributed UAS 12 (FIG. 2b) may be initialized in the same manner.
Preferably, processor 30 begins the initialization process by accessing and executing the control program 72 on the master EKE 70. Under control of program 72, processor 30 first determines 800 whether the UAS 12 is new (i.e. uninitialized). Step 800 is preferably carried out by checking a "new" flag stored in the UAS 12. When a UAS 12 is new, as it is in the present instance, this "new" flag should be set. If the UAS "new" flag is set, then processor 30 proceeds to step 802 to determine whether the master EKE 70 is new. Similar to the UAS 12, a "new" flag is stored on the master EKE 70, and this flag should be set when the master EKE 70 is new. If both "new" flags are found to be set, then processor 30 goes on to implement the initialization process 804 to initialize both the UAS 12 and the master EKE 70 with data that will be used in the recognition and comprehension processes.
The step 804 of initializing the UAS 12 with recognition and comprehension data is shown in greater detail in FIG. 4b. As shown in FIG. 4b, processor 30 starts the data initialization process by prompting 810 the user for a dynamic personal identification number (DPIN) or code. This DPIN may be any desired alpha-numeric which the user wants to use as an identification code. Step 810 is preferably carried out by sending a user prompt to the display subsystem 50 and soliciting a response from the user via the keyboard subsystem 52. Once a DPIN is received from the keyboard subsystem 52, processor 30 proceeds to generate 814 a master hash code and a master key code using the DPIN as input. As will be explained later, this master key code is used to encrypt information stored on the master EKE 70. Preferably, processor 30 generates the master key code in two steps. First, processor 30 executes the hash code generation logic stored in section 62 of the non-volatile memory 38, using the DPIN as input, to generate a master hash code. Processor 30 preferably generates the master hash code by implementing a hashing algorithm. In the preferred embodiment, the Secure Hash Algorithm (SHA), developed by the National Institute of Standards and Technology, and published as a federal information processing standard (FIPS PUB 180), is used as the hashing algorithm. SHA is described in "SHA: The Secure Hash Algorithm" by William Stallings, Dr. Dobb's Journal, April 1994, which is incorporated herein by this reference. A point to note about a hash code is that, given the same input, the same hash code will be generated each and every time. Thus, given the same DPIN, the same master hash code will be generated every time. However, given a certain hash code, the input cannot be derived. This means that an input cannot be "reverse engineered" from a hash code. This feature of a hash code is useful for protecting the identity of the DPIN. Once the master hash code is generated, it is stored in section 62 of the non-volatile memory 38, as shown in FIG. 2a. As will be explained in a later section, the master hash code is used for user verification purposes.
Once the master hash code is generated and stored, it is used by processor 30 to generate the master key code. Preferably, processor 30 generates the master key code by implementing a selected key generation algorithm using the master hash code as input. The key generation algorithm may be any desired algorithm which converts the hash code into a key having a desired length. The specific key generation algorithm used is a matter of design choice. Once the master key code is generated, it is stored in section 62 of the non-volatile memory 38, and in RAM 40 for subsequent reference. Note that the master key code is not stored on the master EKE 70. This is to preclude the possibility of another party extracting the master key code from the master EKE 70 and thereafter decrypting the information on the master EKE using the master key code.
Once the master hash code and the master key code are generated and stored, processor 30 proceeds to step 818 to generate a UAS hash code and a UAS key code. As will be explained later, the UAS key code is used to encrypt information stored in section 60 of the non-volatile memory 38. The UAS hash code and the UAS key code are generated in much the same manner as the master codes described above except that the UAS identification code stored in section 62 of the non-volatile memory 38 is used as an additional input factor. More particularly, processor 30 preferably first combines the UAS identification code with the DPIN to derive a modified DPIN. Then, processor 30 executes the hash code generation logic stored in section 62, using the modified DPIN as input, to generate the UAS hash code. Like the master hash code, the UAS hash code is preferably generated by implementing the SHA. Once generated, the UAS hash code is stored in section 74 of the master EKE 70 for subsequent access.
After the UAS hash code is generated, processor 30 uses it to generate the UAS key code. Preferably, the UAS key code is derived by implementing a selected key generation algorithm (which may be the same key generation algorithm as that used to generate the master key code) to convert the UAS hash code into a UAS key Code having a desired length. Again, the specific key generation algorithm used is a matter of design choice. Once the UAS key code is generated, it is stored in RAM 40 for subsequent access. Note that unlike the master key code, the UAS key code is not stored permanently in section 62 of the non-volatile memory 38, but only in the volatile RAM 40. Since information stored in RAM 40 is lost each time the UAS 12 is deactivated, the UAS key code will need to be newly generated each time the UAS 12 is turned on. The UAS key code is managed in this manner to prevent an unauthorized party from extracting the UAS key code from the non-volatile memory 38 and thereafter using the UAS key code to decrypt the recognition and comprehension parameter information stored in section 60 of the non-volatile memory 38.
After the master key code and the UAS key code are generated, the processor 30 is ready to generate the operational key codes and the operational key file names which will be used in the recognition and comprehension processes. Data generation preferably begins with the processor 30 determining 822 the manner in which an operational key code will be derived. If the user indicates that he wants to manually input an operational key code, then processor 30 simply receives 830 a multi-bit binary code from the user via the keyboard subsystem 52. On the other hand, if the user indicates that he wants the operational key code to be automatically generated, then processor 30 executes the encryption modules 56 to randomly generate 826 a multi-bit binary code which is used as the operational key code. In the preferred embodiment, the operational key code is a 512-bit binary code. The number of bits may vary, however, depending upon which encryption algorithm is implemented by the encryption modules 56. The algorithm implemented by modules 56 is a matter of design choice. Whichever method is used, once an operational key code is derived, processor 30 generates 834 an operational key file name to associate with the operational key code. This key file name, which preferably is a variable length alpha having up to ten characters, is generated by processor 30 by executing the encryption modules 56. Once the operational key file name is generated, processor 30 creates a file in the RAM 40 of the UAS 12, assigns the file the operational key file name, and stores 838 the operational key code as a record in the file. Thereafter, processor 30 determines 842 whether more key codes need to be derived and stored; if so, processor 30 loops back to step 822 to process another key code. Preferably, steps 822-842 are repeated an n number of times to derive and to store an n number of unique operational key codes. In the preferred embodiment, twenty operational key codes are derived, but it should be noted that any desired number of operational key codes may be derived. At the end of this process 822-842, twenty files will be created and stored in the RAM 40 of the UAS 12. As illustrated in FIG. 5a, each file will have a unique operational key file name, and each file will contain a unique operational key code as a record therein. The operational key codes and their corresponding operational key files names are thus established.
Note that the operational key file names and the operational key codes are thus far stored only in the RAM 40 of the UAS 12. This information will be lost once the UAS 12 is deactivated due to the volatile nature of the RAM 40. In order to preserve the information for future reference, the information is preferably stored in section 60 of the non-volatile memory 38, and in section 76 of the master EKE 70. For security reasons, though, it is not desirable to store this information unprotected on either the UAS 12 or the master EKE 70. Because of this security concern, processor 30, in storing the information onto the UAS 12 and the master EKE 70, preferably first encrypts the information. Thus, in step 846, processor 30 preferably first encrypts the operational key codes stored in RAM 40 using the UAS key code as the encryption key. Once that is done, processor 30 stores the encrypted data, including the operational key file names and the encrypted operational key codes, into section 60 of the non-volatile memory 38. Encrypted recognition and comprehension parameters are thus permanently stored in the UAS 12. Similarly, in step 850, processor 30 first encrypts the operational key codes using the master key code (instead of the UAS key code) as the encryption key. Thereafter, processor 30 stores the operational key file names and the encrypted operational key codes into section 76 of the master EKE 70. In both steps 846 and 850, processor 30 preferably carries out the encryption process by executing the encryption modules 56 in non-volatile memory 38. After the encrypted operational key codes and operational key file names are stored, processor 30 proceeds to encrypt and store 852 the UAS identification code (stored in section 62 of the non-volatile memory 38) into section 74 of the master EKE 70. Preferably, the UAS identification code is encrypted using the master key code as the encryption key. After step 852, both the UAS 12 and the master EKE 70 are fully initialized. All that remains is for processor 30 to reset 854 the "new" flags in both the UAS 12 and the master EKE 70 to indicate that the devices are no longer new. Once that is done, initialization is complete.
Restoration and Backup Functions of the Master EKE
Thus far, the master EKE control program 72 has been described only with regard to the initialization process. It should be noted, though, that program 72 is capable of performing several other important functions. These functions include UAS recovery, master EKE recovery, and DPIN replacement and updating. These functions become important as the system 10 is used over a long period of time. To elaborate, in the course of using the system 10, it is probably inevitable that a user will at one time or another lose the UAS 12, lose the master EKE 70, or forget the DPIN. Without an effective recovery mechanism, the loss of one of these components could cause system functionality to be lost. One of the great advantages of the system 10 of the present invention is that, given any two of the three components (master EKE, UAS, DPIN), system recovery can be achieved. Hence, the loss of one component will not jeopardize system functionality. With reference to FIGS. 4a, 4c, 4d, and 4e, the other functions of the master EKE control program 72 will now be described.
UAS Recovery
One of the loss/recovery scenarios that can arise in the system of the present invention is that of a user losing the UAS 12. If the user still has the master EKE 70, and still remembers the DPIN, a new UAS 12 can be set up to function in the same manner as the lost UAS. To properly configure the new UAS, a user first inserts the master EKE 70 into the user interface 32 of the new UAS. Thereafter, the processor 30 on the new UAS 12 accesses and executes the control program 72 on the master EKE 70 to implement the recovery process. Specifically, the processor 30, under control of program 72, determines 800, 802 (FIG. 4a) whether the UAS 12 and the master EKE 70 are new. In the present scenario, the processor 30 will find that the UAS 12 is new but that the master EKE 70 is not new. Given these conditions, processor 30 will branch to step 860 to implement the UAS restoration process.
Step 860 is shown in greater detail in FIG. 4c. The UAS recovery process begins with the processor 30 prompting 862 the user for a DPIN. Once the DPIN is received from the user via the keyboard subsystem 52, the processor 30 uses the DPIN to generate 864 a master key code. Preferably, step 864 is performed by first executing the hash code generation logic stored in section 62 of the new UAS 12 (which preferably causes the SHA previously discussed to be implemented) to generate a master hash code. Then, using the master hash code as input, processor 30 implements a selected key generation algorithm to generate a master key code. Preferably, the key generation algorithm implemented in this process is the same as that previously described in connection with step 814 of FIG. 4b.
Once generated, the master key code is used by processor 30 to verify 866 the accuracy of the DPIN provided by the user. The DPIN verification process 866 involves four major steps. First, processor 30 uses the generated master key code to decrypt the encrypted UAS ID code stored in section 74 of the master EKE 70 to derive a decrypted UAS ID code. This step is preferably carried out by executing the encryption modules 56. Thereafter, processor 30 combines the decrypted UAS ID code with the DPIN to derive a modified DPIN. Then, using the modified DPIN as input, processor 30 executes the hash code generation logic in section 62 of the non-volatile memory 38 to generate a UAS hash code. Finally, processor 30 compares the generated UAS hash code with the UAS hash code already stored on the master EKE 70 to determine whether they are consistent. If they are not consistent, then it means that an improper DPIN was entered by the user. In such a case, processor 30 terminates operation. On the other hand, if processor 30 determines that the two hash codes are consistent, thereby meaning that the proper DPIN was entered, then UAS restoration is allowed to continue.
If it is determined that the proper DPIN was entered, then processor 30 proceeds to step 870 to decrypt the encrypted recognition and comprehension parameters stored in section 76 of the master EKE 70. Preferably, processor 30 decrypts the encrypted parameters by executing encryption modules 56, using the master key code as the decryption key. Once decrypted, the operational key codes and key file names are stored 874 in the RAM 40 of the new UAS 12.
Thereafter, processor 30 proceeds to step 878 to generate a new UAS hash code and a new UAS key code. In generating the new UAS hash code, processor 30 first derives a new modified DPIN by combining the new UAS ID code stored in section 62 of the new UAS 12 with the DPIN. Once the new modified DPIN is derived, processor 30 generates the new UAS hash code by executing the hash code generation logic stored in section 62 of the new UAS, using the new modified DPIN as input. Once generated, the new UAS hash code is stored in section 74 of the master EKE 70 replacing the old UAS hash code which is currently residing therein. Then, using the new UAS hash code as input, processor 30 implements a key generation algorithm to generate a new UAS key code. Preferably, the key generation algorithm used in this process is the same as that previously described in connection with step 818 of FIG. 4b. Note that the new UAS key code will be different from that used by the lost UAS. This is because the new modified DPIN used to generate the new UAS key code is different (due to the different UAS ID code) from the modified DPIN used to generate the UAS key code used by the lost UAS. This different UAS key code will not prevent the new UAS from achieving identical functionality, however.
Once the new UAS key code is derived, it is stored in RAM 40 of the new UAS 12 for subsequent reference. It is also used by processor 30 to encrypt 882 the operational key codes stored in RAM 40. Preferably, step 882 is carried out by executing the encryption modules 56, using the new UAS key code as the encryption key. After the operational key codes are encrypted, processor 30 stores 886 the operational key file names and the encrypted operational key codes (i.e. the encrypted recognition and comprehension parameters) into section 60 of the non-volatile memory 38 of the new UAS 12 for subsequent reference.
To complete the UAS restoration process, processor 30 preferably carries out four more steps. First, processor 30 stores 890 the previously generated master hash code and master key code into section 62 of the non-volatile memory 38 for subsequent reference. Second, processor 30 encrypts 894 the new UAS identification code stored in section 62 of the non-volatile memory 38 using the master key code as the encryption key, and thereafter stores the encrypted new UAS ID code into section 74 of the master EKE 70. Third, processor 30 preferably deletes 898 the encrypted UAS identification code of the lost UAS from section 74 of the master EKE 70. Finally, processor 30 resets 900 the "new" flag on the new UAS to indicate that the UAS has now been initialized. The UAS restoration process is now complete.
Master EKE Recovery
Another loss/recovery scenario which may arise is one in which the user loses the master EKE 70. If the user still has the UAS 12, and still remembers the DPIN, a new master EKE 70 can be configured to function in the same manner as the lost master EKE. To properly configure a new master EKE, the new master EKE 70 is inserted into interface 32 of the UAS 12. Thereafter, the processor 30 accesses and executes the control program 72 on the new master EKE. Under control of program 72, processor 30 begins processing by determining 800, 910 (FIG. 4a) whether the UAS 12 and the new master EKE 70 are new. In this particular instance, the processor 30 will find the UAS 12 to be already initialized but the master EKE 70 to be new. Given these conditions, the processor 30 will branch to step 912 to implement the master EKE restoration process. Step 912 is shown in greater detail in FIG. 4d.
Processor 30 preferably begins the restoration process 912 by prompting 916 the user for a DPIN. When the DPIN from the user is received via the keyboard subsystem 52, processor 30 uses the DPIN to generate 918 a master hash code. Processor 30 preferably generates the master hash code by executing the hash code generation logic stored in section 62 of the non-volatile memory 38, using the DPIN as input. Once generated, the master hash code is used to verify 920 the accuracy of the DPIN. Processor 30 preferably carries out step 920 by comparing the generated master hash code with the master hash code already stored in section 62 of the non-volatile memory 38. If the two hash codes are inconsistent, then it means that an improper DPIN was entered by the user. In such an instance, processor 30 terminates operation. On the other hand, if the two hash codes are consistent, then the validity of the DPIN is verified and the master EKE restoration process is allowed to continue.
If the proper DPIN was entered, then processor 30 proceeds to step 924 to generate a UAS hash code and a UAS key code. In generating the UAS hash code, processor 30 preferably performs several sub-steps. First, processor 30 combines the UAS identification code stored in section 62 of the non-volatile memory 38 with the DPIN to derive a modified DPIN. Then, processor 30 uses the modified DPIN to generate the UAS hash code. Preferably, the UAS hash code is generated by executing the hash code generation logic stored in section 62, using the modified DPIN as input. Once generated, the UAS hash code is preferably stored in section 74 of the new master EKE 70. Thereafter, processor 30 generates the UAS key code by implementing the key generation algorithm described above in connection with step 818 of FIG. 4b, using the generated UAS hash code as input. Once the UAS key code is derived, it is stored in RAM 40. Thereafter, processor 30 uses the UAS key code to decrypt 928 the encrypted recognition and comprehension parameters stored in section 60 of the non-volatile memory 38. Step 928 is preferably carried out by executing modules 56. The operational key codes are thus decrypted and derived. Once decrypted, the operational key codes and the operational key file names are stored in RAM 40.
After step 928, processor 30 prepares to store the recognition and comprehension parameters onto the new master EKE 70. Before storing the parameters, though, processor 30 preferably first reencrypts 932 the recognition and comprehension parameters (i.e. the operational key file names and operational key codes) stored in the RAM 40 using a master key code as the encryption key. The master key code may be retrieved from section 62 of the non-volatile memory or, if so desired, may be newly generated using the DPIN. In addition, processor 30 also preferably encrypts the UAS identification code stored in section 62 of the non-volatile memory 38 using the master key code as the encryption key. Once step 932 is carried out, processor 30 stores 936 the encrypted recognition and comprehension parameters into section 76 of the new master EKE 70, and the encrypted UAS identification code into section 74 of the new master EKE 70. The new master EKE 70 is now configured to function in the same manner as the lost master EKE. All that remains for the processor 30 to do is to reset 940 the "new" flag on the master EKE 70 to indicate that the master EKE is no longer uninitialized. Once that is done, the master EKE restoration process is complete.
DPIN Modification/Recovery
One other loss/recovery scenario to be considered is the one in which the user forgets the DPIN used to generate the master and UAS key codes. As made clear by the above discussions, the DPIN plays a vital role in the proper encryption and decryption of the recognition and comprehension parameters. To recover from the loss of the DPIN, the user will need to have both the original UAS 12 and the original master EKE 70. The user initiates the recovery process by inserting the master EKE 70 into interface 32 of the UAS 12. Thereafter, the processor 30 accesses and executes the control program 72 on the master EKE 70 to implement the recovery process. As shown in FIG. 4a, processor 30, under control of program 72, begins operation by determining 800, 910 whether the UAS 12 and the master EKE 70 are new. In this particular instance, neither component is new; hence, processor 30 will proceed to step 942.
In step 942, processor 30 implements a recognition methodology to determine whether the UAS 12 and the master EKE 70 are authorized to interact with each other at all. Preferably, processor 30 carries out step 942 by first retrieving the master key code previously stored in section 62 of the non-volatile memory 38. Thereafter, processor 30 uses the master key code to decrypt the encrypted UAS identification code stored in section 74 of the master EKE 70. Once decrypted, the UAS identification code from the master EKE 70 is compared with the UAS identification code stored in section 62 of the non-volatile memory 38. If the two codes are not consistent, then the two components 12, 70 are not authorized to interact with each other. Hence, communication therebetween is terminated. On the other hand, if the two codes are consistent, then authorization is verified, and the processor 30 is allowed to proceed to step 946.
It is in steps 946 and 948 that the user is allowed to override the current DPIN and to establish a new DPIN. Specifically, in step 946, processor 30 queries the user as to whether the user wishes to set a new DPIN. If so, then processor 30 implements the DPIN modification process 948. Step 948 is shown in greater detail in FIG. 4e, wherein the first step in the DPIN modification process is to retrieve 980 the master key code previously stored in section 62 of the non-volatile memory 38. Once retrieved, this master key code is used by the processor 30 to decrypt 982 the encrypted recognition and comprehension parameters stored in section 76 of the master EKE 70. The recognition and comprehension parameters (i.e. the operational key codes and operational key file names) are thus derived. Once derived, the parameters are stored 984 in RAM 40 for subsequent reference.
Thereafter, processor 30 prompts 986 the user for a new DPIN with which to replace the forgotten DPIN. Upon receiving the new DPIN via the keyboard subsystem 52, processor 30 proceeds to generate 988 a new master key code. Preferably, processor 30 generates the new master key code in two steps. First, processor 30 executes the hash code generation logic stored in section 62 of the non-volatile memory 38, using the new DPIN as input, to generate a new master hash code. This new master hash code is stored in section 62 of the non-volatile memory 38, preferably replacing the master hash code currently stored therein. Then, using the new master hash code as input, processor 30 implements a key generation algorithm to generate a new master key code having a desired length. Preferably, the key generation algorithm implemented here is the same as that previously described in connection with step 814 of FIG. 4b. Once generated, the new master key code is preferably stored both in section 62 of the non-volatile memory 38 and in RAM 40. Thereafter, the new master key code is used by the processor 30 to encrypt 990 both the parameters stored in the RAM 40 and the UAS identification code stored in section 62 of the non-volatile memory 38. Once that is done, processor 30 stores 992 the encrypted recognition and comprehension parameters into section 76 of the master EKE 70, and the encrypted UAS identification code into section 74 of the master EKE 70. Preferably, once this new encrypted information is stored in sections 74 and 76, the information previously stored in these same sections is deleted. Master EKE 70 is thus updated.
A similar process is performed by processor 30 to update the UAS 12. Specifically, processor 30 begins the UAS updating process by generating 994 a new UAS hash code and a new UAS key code. Preferably, processor 30 generates the new UAS hash code by combining the UAS identification code stored in section 62 with the new DPIN to derive a modified DPIN. Then, using the modified DPIN as input, processor 30 executes the hash code generation logic stored in section 62 of the non-volatile memory 38 to generate the new UAS hash code. Once generated, the new UAS hash code is stored in section 74 of the master EKE 70, preferably replacing the UAS hash code previously stored therein. Thereafter, processor 30 uses the new UAS hash code to generate the new UAS key code. Preferably, processor 30 generates the new UAS key code by implementing a key generation algorithm, using the new UAS hash code as input. The key generation algorithm implemented here is preferably the same as that previously described in connection with step 818 of FIG. 4b. Once the new UAS key code is generated, it is stored in RAM 40 and is used as an encryption key by processor 30 to encrypt 996 the recognition and comprehension parameters stored in the RAM 40. Once that is performed, processor 30 stores 998 the encrypted recognition and comprehension parameters into section 60 of the non-volatile memory 38 for future reference. As an additional step, processor 30 preferably deletes the encrypted parameters previously stored in section 60. After step 998 is performed, the DPIN modification process is complete. As shown by this discussion, the system of the present invention is quite robust in that it can recover from the loss of any one of these three components: UAS, master EKE, and DPIN.
Other Functions of the Master EKE
Thus far, the master EKE control program 72 has been described as being used only in the initialization and recovery processes. However, as shown in FIG. 4a, control program 72 is also capable of performing several other functions. One such function is that of override. More specifically, steps 954 and 956 may be implemented (if a user so wishes) to change the recognition and comprehension parameters currently stored in the UAS 12 and the master EKE. New operational key codes and operational key file names may be generated in much the same manner as that described in conjunction with FIG. 4b. Hence, step 956 need not be described in detail here.
Another additional function performed by the master EKE control program 72 is that of data backup. Note that the recognition and comprehension parameters are encrypted and stored not only in the UAS 12 but also in the master EKE 70. This extra storing procedure is performed to ensure that, if the information stored in UAS 12 is somehow lost or erased, the information can be restored by consulting the master EKE 70. Steps 950-952 of FIG. 4a deal with this backup aspect of the master EKE control program 72. Whenever program 72 is executed by processor 30, the user is given an option 950 to restore information into the UAS 12. If the user chooses this option, then processor 30 preferably performs step 952, which involves a series of sub-steps. In carrying out step 952, processor 30 first uses the master key code stored in section 62 of the UAS 12 to decrypt the encrypted parameter information stored in section 76 of the master EKE 72. The parameters, thus decrypted, are stored in RAM 40. Then, processor 30 prompts the user for a DPIN. Upon receiving the DPIN, the processor 30 generates a master hash code in the manner described above. Once generated, this master hash code is used to verify the validity of the entered DPIN. More specifically, the generated master hash code is compared with the master hash code stored in section 62 of the non-volatile memory 38. If the two hash codes are consistent, then it is verified that the entered DPIN is accurate. After the DPIN is verified, processor 30 generates a UAS key code. This is preferably achieved by first generating a UAS hash code, and then using the UAS hash code to generate the UAS key code, in the manner described above. Once generated, the UAS key code is used as an encryption key to encrypt the parameters stored in RAM 40. Once that is done, processor 30 stores the encrypted parameters into section 60 of the non-volatile memory 38. Data restoration is thus achieved.
One further point should be noted regarding the data backup aspect of the control program 72. In normal use, the UAS 12 is operated without the master EKE 70. Also, in normal operation, the recognition and comprehension parameters stored in section 60 of the non-volatile memory 38 of the UAS 12 can be updated. Thus, at times, section 60 of the non-volatile memory 38 will contain fresh or updated information that is not stored on the master EKE 70. Preferably, processor 30 sets a "new data" flag whenever any new or modified data is stored in section 60, and whenever existing data is deleted from section 60. That way, whenever the master EKE 70 is inserted and the master EKE control program 72 is executed, the processor 30 can check 958 for the "new data" flag, and if the flag is set, then processor 30 can store 960 the updated data from section 60 into the master EKE 70. Preferably, processor 30 performs step 960 by first generating a UAS key code in the manner described above. Then, the UAS key code is used to decrypt all of the encrypted parameters stored in section 60 of the non-volatile memory 38. Once that is done, the decrypted recognition and comprehension parameters are stored in RAM 40. Thereafter, processor 30 uses the master key code stored in section 62 of the non-volatile memory 38 to encrypt the decrypted parameters in the RAM 40. Then, processor 30 stores the newly encrypted recognition and comprehension parameters into section 76 of the master EKE 70, preferably replacing the parameters previously stored therein. The master EKE 70 is thus updated. Once the new data is backed up onto the master EKE 70, processor 30 resets the "new data" flag. By updating the master EKE 70 in this manner, the master EKE control program 72 optimizes the master EKE's ability to function effectively as a backup device.
UAS Start-up
Once UAS 12 is initialized as described above, the master EKE 70 is decoupled from the storage device interface 32 of the UAS 12. The UAS 12 is thereafter able to receive a regular EKE 14 through interface 32. Recall that when the UAS 12 was initialized, the recognition and comprehension parameters were stored in section 60 of the non-volatile memory 30 in encrypted form. Before these parameters can be used in actual operation, they first need to be decrypted. This decryption function is preferably performed by the processor 30 under control of the decryption logic stored in section 62 of the non-volatile memory 38 each time the UAS is powered up. A flow diagram for this decryption logic is shown in FIG. 4f. With reference to FIG. 4f, processor 30 begins the decryption process by prompting 1000 the user to enter a DPIN. Once the DPIN is received via the keyboard subsystem 52, processor 30 uses the DPIN to generate 1002 a master hash code. Preferably, processor 30 generates the master hash code by executing the hash code generation logic stored in section 62 of the non-volatile memory 38, using the DPIN as input. Once generated, the master hash code is compared 1004 with the master hash code stored in section 62 of the non-volatile memory 38. If the two hash codes are inconsistent, then it means that an improper DPIN was entered by the user. In such a case, processor 30 terminates operation to prevent an unauthorized user from using the UAS 12. On the other hand, if the two hash codes are consistent, then processor 30 proceeds to step 1008.
In step 1008, processor 30 uses the DPIN to generate a UAS key code. More specifically, processor 30 preferably first combines the UAS ID code stored in section 62 of the non-volatile memory 38 with the DPIN to derive a modified DPIN. Then, using the modified DPIN as input, processor 30 executes the hash code generation logic stored in section 62 to generate a UAS hash code. Once generated, the UAS hash code is used by processor 30 to generate a UAS key code. More specifically, processor 30 implements a key generation algorithm (preferably the same as that discussed above with regard to step 818 of FIG. 4b) using the UAS hash code as input to generate a UAS key code having a desired length. Once generated, the UAS key code is stored 1010 in RAM 40 for subsequent reference. Thereafter, processor 30 uses the UAS key code as a decryption key to decrypt 1012 the recognition and comprehension parameters stored in section 60 of the non-volatile memory 38. Preferably, processor 30 carries out step 1012 by executing the encryption modules 56. Once decrypted, the recognition and comprehension parameters (i.e. the operational key file names and operational key codes) are stored 1014 in the RAM 40 of the UAS 12. The parameters are now in a form which can be used in normal operation. Thus, the UAS 12 is now ready for operation with a regular EKE 14. One additional point to note is that because the decrypted parameters and the UAS key code are stored in the volatile RAM 40 of the UAS 12, this information will be lost when the UAS 12 is deactivated. This means that the decrypted parameters and the UAS key code will need to be newly generated the next time the UAS 12 is used. Hence, processor 30 preferably executes the decryption logic stored in section. 62 of the non-volatile memory 38 each time the UAS 12 is powered up.
Thus far, the process (shown in FIG. 4f) of verifying the accuracy of the DPIN and of decrypting the recognition and comprehension parameters has been described as being implemented by processor 30 under control of the decryption logic in section 62 of the non-volatile memory 38. It should be noted, however, that the process shown in FIG. 4f may also be implemented by way of a hardwired circuit. The design of such a circuit, given FIG. 4f, is within the skill of one of ordinary skill in the art. Such an implementation is within the contemplation of the present invention.
EKE
Once the UAS 12 is powered up, and the recognition and comprehension parameters are decrypted and stored in RAM 40, the UAS 12 is ready to interact with a regular EKE. With reference to FIG. 6, there is shown a detailed block diagram of an EKE 14 of the present invention. In the preferred embodiment, EKE 14 takes the form of a PCMCIA memory card having a PCMCIA interface (not shown) for coupling to interface 32 of the UAS 12. As shown in FIG. 6, EKE 14 preferably stores a plurality of data files 148-170, and at least two control programs: (1) the PAMS file manager (PFM) 140; and (2) the provider-specific software 141. Optionally, EKE 14 may store a third control program 172 (the encryption modules) which may be executed to perform encryption/decryption functions.
On EKE 14, the PFM 140 is the main program which is accessed and executed by processor 30 to coordinate interaction among all of the components 12, 14, 16, 18 of the system 10. PFM 140 preferably comprises a UAS-EKE interaction control portion 142 for controlling interaction between the UAS 12 and the EKE 14, and a user device-PAS control portion 144 for coordinating interaction between a user device (formed by UAS 12 and EKE 14) and the PAS 18. Control portion 142 is the portion which is accessed and executed first by processor 30.
When executed, control portion 142 preferably causes processor 30 to perform a number of different functions. First, portion 142 causes processor 30 to implement a recognition methodology to verify that UAS 12 and EKE 14 are authorized to interact with each other. If interaction is not authorized, then portion 142 terminates communication with the UAS 12. This verification function is important because it renders an EKE 14 usable with only one particular UAS 12 (referred to herein as the "principal UAS"). This means that if the EKE 14 is lost or stolen, system security is not compromised because the holder of the lost or stolen EKE 14 will not be able to use the EKE with his own UAS 12. Thus, control portion 142 greatly enhances system security. Second, portion 142 causes processor 30 to strictly coordinate access to the other resources stored on the EKE 14, such as the managed files 154-164, 170. This adds an extra layer of protection, just in case a user is somehow able to obtain authorization fraudulently. Third, portion 142 causes processor 30 to coordinate the encryption and decryption of data stored in the files 154-164, 170. This encryption or comprehension function ensures that even if the EKE 14 is lost, no comprehensible information can be extracted therefrom. Fourth, portion 142 causes processor 30 to coordinate the dynamic alteration and update of the parameters used in the above three functions. By dynamically and regularly changing these parameters, portion 142 makes it virtually impossible for anyone to ascertain, at any particular time, what parameters are being used. This in turn makes it extremely difficult to "break in" to the system 10. Therefore, portion 142 of PFM 140 ensures the security of the EKE 14.
PFM 140 also preferably comprises a user device-PAS interaction control portion 144 for coordinating interaction between the user device 16 and the PAS 18. Control portion 144, when executed by processor 30, preferably causes the processor 30 to properly coordinate the exchange of information with the PAS 18. In performing this coordination function, portion 144 preferably causes the user device 16 to implement the unique recognition and comprehension methodologies of the present invention, in conjunction with the provider device 18, to verify party identities and to ensure session security. By so doing, portion 144 ensures that only proper devices will be allowed to communicate with each other, and that information transferred between the user device 16 and the PAS 18 will be secure from third parties. Together, portions 142 and 144 coordinate the overall secure operation of the UAS-EKE assembly.
The provider-specific software 141 on the EKE 14 provides the program instructions necessary for communicating with a particular provider or a particular group of providers. Program 141 preferably includes an application portion 145 for generating the messages or session codes which are sent to the PAS 18, and a communications portion 146 for organizing the information sent to the PAS 18 in a manner expected by the PAS 18. These program portions 145, 146 are executed under the direction of portion 144 of the PFM 140. As the name suggests, provider-specific software 141 is preferably tailored to communicate with one or a group of specific providers. Consequently, the application 145 and the communications 146 portions can and probably will be customized for each provider, which means that software 141 will vary from EKE to EKE. In contrast, the PFM 140, because it is not necessarily provider-specific, may be identical for all EKE's. In the preferred embodiment shown in FIG. 6, there is only one provider-specific program 141 stored on the EKE 14. However, if so desired, an EKE 14 may store more than one provider-specific program to allow a user to communicate with a plurality of providers using only one EKE 14. Such a modification is within the scope of the present invention.
The data files, also referred to herein as storage units, 148-170 on the EKE 14 contain user-specific (i.e. EKE-specific) data which are manipulated by PFM 140 in carrying out its recognition and comprehension methodologies. More specifically, PFM 140 uses the information in these data files 148-170 to determine whether the UAS 12 and the EKE 14 are authorized to interact, to manage access and updates to files on the EKE 14, and to communicate with the PAS 18. Some of the information in the data files or storage units will be provided by the provider, while some of the information will be generated by the PFM 140. More will be said about data files 148-170 in later sections as the operation of the UAS 12, the EKE 14, and the PAS 18 is described.
Protection of the Information on the EKE
In the preferred embodiment, the EKE 14 is a portable, compact memory card. As such, the EKE 14 is quite easy to lose. To prevent a third party from being able to extract useful information from a lost EKE 14, selected files and programs on the EKE 14 are preferably stored encrypted at all times. Portions of the EKE 14 which are encrypted include: (1) PFM 140 (except unencrypted portion 143); (2) managed files 152-164; and (3) a portion of file 170. Due to the nature in which some of the files are used, some of the files on the EKE 14 (e.g. files 148, 150, 167, 168) are left unencrypted. In the preferred embodiment, the provider-specific software 141 is left unencrypted; however, if so desired, software 141 may also be stored on EKE 14 in encrypted form.
The PFM 140 is stored on EKE 14 in encrypted form in order to prevent an unauthorized party from tampering with, and thereby altering, the program instructions. Note, however, that not all of the PFM 140 is stored in encrypted form. A relatively small portion 143 of the UAS-EKE control portion 142 is left unencrypted to allow the processor 30 to initially interface with the EKE 14. The instructions in portion 143 are analogous to boot-up code. To elaborate, when EKE 14 is coupled to interface 32 of the UAS 12, the processor 30 first accesses and executes the unencrypted portion 143 of UAS-EKE control portion 142. Under control of portion 143, processor 30 performs checks to determine whether to proceed further. If certain requirements are met, then processor 30 is allowed to decrypt the remainder of portion 142 and the entirety of portion 144, and to store the decrypted instructions into the RAM 40 of the UAS 12. Thereafter, processor 30 is allowed to execute the decrypted PFM instructions stored in the RAM 40 to carry out the functions dictated by the PFM 140. By managing the PFM 140 in this manner, it is possible to both protect the integrity of the PFM (by encryption) and to provide a convenient interface between the UAS 12 and the EKE 14. With this background information in mind, interaction between the UAS 12 and the EKE 14 will now be described in greater detail.
UAS-EKE Interaction
An overall user device 16 is formed by coupling the EKE 14 to the UAS 12 via the storage device interface 32. Once coupled, the processor 30 on the UAS 12 accesses and executes the PFM 140 stored on the EKE 14. More specifically, processor 30 first accesses and executes the unencrypted portion 143 of the UAS-EKE interaction control portion 142. Under control of portion 143, processor 30 begins the process of controlling interaction between the UAS 12 and the EKE 14. To describe portions 143 and 142 in greater detail, reference will now be made to FIGS. 7a-7f. FIG. 7a provides an overall operational flow diagram for portion 142, including those parts which pertain to the unencrypted portion 143, while FIGS. 7b-7f provide more detailed flow diagrams for selected aspects of portion 142.
Referring now to FIG. 7a, the portions of FIG. 7a which pertain to the unencrypted portion 143 include: (1) processes 174-180; (2) processes 184-190; (3) processes 216-224; and (4) processes 225-227. In other words, unencrypted portion 143 comprises the instructions necessary for carrying out processes 174-180, 184-190, 216-224, and 225-227. The remaining processes 191-214 shown in FIG. 7a pertain to the remainder of the UAS-EKE interaction control portion 142. The instructions necessary for implementing these remaining processes 191-214 are preferably stored on the EKE 14 in encrypted form.
As mentioned above, when EKE 14 is interfaced with UAS 12, processor 30 accesses and executes the unencrypted instructions stored in portion 143. Under control of portion 143, processor 30 begins operation by determining 174 whether encryption modules 172 are stored on the EKE 14. If not, then processor 30 proceeds to step 177. However, if encryption modules 172 are found on the EKE 14, then processor 30 loads 175 the encryption modules 172 into the RAM 40, and sets 176 an "override" flag. If the "override" flag is set, then all subsequent encryption/decryption functions will be carried out by executing the encryption modules stored in RAM 40 instead of executing the encryption modules 56 stored in the UAS 12. This feature of the invention allows a provider to dictate, by storing modules 172 on the EKE 14, the particular encryption algorithm to be used. This is a very useful feature, especially if the encryption modules 56 stored in the UAS 12 become obsolete. For the sake of simplicity, though, it will be assumed for the purposes of description that EKE 14 does not contain a set of overriding encryption modules 172. Thus, the invention will be described hereinafter with reference to the encryption modules 56 in the UAS 12.
Initialization of a New EKE
After determining whether to load encryption modules into the RAM 40, processor 30 goes on to step 177, wherein it is determined whether the EKE 14 is new, i.e. uninitialized. Preferably this determination is made by looking for an operational key file name in file 148 of the EKE 14. If no operational key file name is stored in file 148, then the EKE 14 has not yet been used. If EKE 14 is new, then processor 30 proceeds to step 178 to begin implementing an initial decrypting process. To elaborate, when a user first receives an EKE 14, the PFM 140 and the data files 152-164 on the EKE 14 are incomprehensible because they are stored in encrypted form. The key needed to decrypt these files is known only to the provider. This is done in order to protect the information on the EKE 14 from unauthorized third parties during possible transport. When the provider gives the new EKE 14 to the user, the provider also preferably gives the user the key (referred to hereinafter as the "initial key code") used to encrypt the PFM and the data files. For security reasons, separate means are preferably used to convey the EKE 14 and the initial key code to the user so that a third party cannot link the key to the EKE 14. Armed with the initial key code, the user can access the resources on the EKE 14.
Referring again to FIG. 7a, once it has been determined that the EKE 14 is new, processor 30 prompts 178 the user to provide the initial key code used to encrypt the PFM 140 and the data files 152-164 on the new EKE 14. Once this key code is received from the user via the keyboard subsystem 52, processor 30 uses the key code to decrypt 179 the encrypted portions of the PFM 140, including the encrypted portion of the UAS-EKE control portion 142, and the user device-PAS control portion 144. Preferably, step 179 is carried out by executing encryption modules 56. After the PFM 140 is decrypted, it is stored 180 in its entirety (including the unencrypted portion 143) in RAM 40. FIG. 9a shows the contents of RAM 40 after this decryption process. As shown, RAM 40 now contains an unencrypted version 1140 of the PFM 140 stored on the EKE 14. The unencrypted PFM 1140 preferably comprises an unencrypted UAS-EKE interaction control portion 1142 which corresponds to portions 143 and 142 on the EKE 14, and an unencrypted user device-PAS interaction control portion 1144 which corresponds to portion 144 on the EKE 14. In addition, RAM 40 also contains a UAS key code and a decrypted version 1160 of the recognition and comprehension parameters stored in section 60 of the non-volatile memory 38. These parameters 1160 were stored in the RAM 40 upon power-up of the UAS 12.
Before going further, it should be noted here that the PFM 140 on the EKE 14 is not altered by this decryption process. The PFM 140 is still stored on EKE 14 in encrypted form. The only unencrypted version of the PFM 140 is in the RAM 40. The PFM 140 on the EKE 14 remains encrypted so that there is never a time at which the PFM 140 is left unprotected.
Once the PFM 140 is decrypted and stored in RAM 40, processor 30 begins executing the unencrypted PFM instructions 1140 stored in the RAM 40. At this point, processor 30 is still controlling interaction between the UAS 12 and the EKE 14. Thus, processor 30 continues operation by executing the unencrypted instructions in portion 1142. Under control of portion 1142, processor 30 proceeds to step 182 to establish a unique relationship between the UAS 12 and the EKE 14. In other words, processor 30 proceeds to initialize the new EKE 14. As an overview, the initialization process has two major objectives. First the process stores customized recognition data in both the UAS 12 and the EKE 14 to establish a unique relationship between the two components. This serves to render the EKE 14 inoperable with any other UAS 12. Second, the initialization process establishes file management parameters which are used later to coordinate access to the managed files 154-164, 170.
The initialization process is shown in greater detail in FIG. 7b. Preferably, processor 30 begins the process by selecting 230 one of the operational key file names stored in section 1160 (FIG. 9a) of the RAM 40. Once selected, the operational key file name is stored 232 in file 148 of the EKE 14. Then, using the selected operational key file name, processor 30 retrieves 234 the operational key code corresponding to the selected operational key file name. For example, with reference to FIG. 5a (whic |
