Personal access management system5689564
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 am 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 sending device having a set of parameters stored therein including a device file name which uniquely identifies the sending device to a receiving device and a set of identification information, a method for exchanging information with the receiving device, comprising the steps of:
generating a message;
retrieving said device file name and said set of identification information;
deriving a first key code from said parameters;
encrypting said identification information and said message using said first key code as an encryption key to derive a set of encrypted identification information and an encrypted
sending said device file name, said encrypted identification information, and said encrypted message to the receiving device, wherein said device file name is sent to the receiving device in unencrypted form.
2. In a sending device having a set of parameters stored therein including a device file name which uniquely identifies the sending device to a receiving device and a set of identification information, a method for exchanging information with the receiving device, comprising the steps of:
generating a message, said message including a request and an accompanying authorization code required by the receiving device in order to process said request;
retrieving said device file name and said set of identification information;
deriving a first key code from said parameters;
processing said identification information using said first key code to derive a set of processed identification information; and
sending said device file name, said processed identification information, and said message to the receiving device.
3. In a sending device having a set of parameters stored therein including a device file name which uniquely identifies the sending device to a receiving device and a set of identification information, a method for exchanging information with the receiving device, comprising the steps of:
generating a message, said message including an instruction for the receiving device to change a current authorization code, said instruction being accompanied by said current authorization code and a new authorization code;
retrieving said device file name and said set of identification information;
deriving a first key code from said parameters;
processing said identification information using said first key code to derive a set of processed identification information; and
sending said device file name, said processed identification information, and said message receiving a device.
4. In sending device having a set of parameters stored therein including a device file name which uniquely identifies the sending, device to a receiving device and a set of identification information, a method for exchanging information with the receiving device, comprising the steps of:
generating a message;
retrieving said device file name and said set of identification information; deriving a first key code from said parameters;
processing said identification information using said first key code to derive a set of processed identification information;
sending said device file name, said processed identification information, and said message to the receiving device;
receiving a set of processed confirmation information from the receiving device;
deriving a second key code different from said first key code; and
processing said processed confirmation information using said second key code to derive a set of de-processed confirmation information.
5. The method of claim 4, further comprising the steps of:
extracting a de-processed device file name from said de-processed information;
comparing said de-processed device file name with said device file name; and
disregarding said de-processed confirmation information in response to a determination that said de-processed device file name is inconsistent with said device file name.
6. The method of claim 4, wherein said de-processed confirmation information includes a provider historical file entry and an accompanying entry designation, and wherein said method further comprises the step of:
storing said provider historical file entry and said entry designation into a provider historical file maintained in the sending device.
7. The method of claim 4, wherein said de-processed information includes a new device file name, and wherein said method further comprises the steps of:
generating a second message; and
sending at least said new device file name and said second message to the receiving device.
8. The method of claim 4, wherein said de-processed confirmation information includes a set of new parameters, and wherein said method further comprises the steps of:
generating a new message;
deriving a new key code from said new parameters;
processing said new message using said new key code to derive a processed new message; and
sending at least said processed new message to the receiving device.
9. In sending device having a set of parameters stored therein including a device file name which uniquely identifies the sending device to a receiving device and a set of identification information, a method for exchanging information with the receiving device, comprising the steps of:
generating a message;
retrieving said device file name and said set of identification information;
deriving a first key code from said parameters;
processing said identification information using said first key code to derive a set of processed identification information;
generating a new parameter; and
sending said device file name, said processed identification information, said message, and said new parameter to the device.
10. The method of claim 9, further comprising the steps of:
generating a new message;
deriving a new key code using said new parameter;
processing said new message using said new key code to derive a processed new message; and
sending at least said processed new message to the receiving device.
11. In a sending device having a set of parameters stored therein including a device file name which uniquely identifies the sending device to a receiving device, a set of identification information, a current user key code (CUKC), and a current provider key code (CPKC), a method for exchanging information with the receiving device, comprising the steps of:
generating a message;
generating a future user key code (FUKC);
deriving a current session key code (CSKC) using said CUKC and said CPKC;
encrypting said identification information, said message, and said FUKC using said CSKC as an encryption key to derive a set of encrypted identification information, an encrypted message, and an encrypted FUKC; and
sending said device file name, said encrypted identification information, said encrypted message, and said encrypted FUKC to the receiving device.
12. The method of claim 11, wherein said device file name is sent to the receiving device in unencrypted form.
13. In a sending device having a set of parameters stored therein including a device file name which uniquely identifies the sending device to a receiving device, a set of identification information, a current user key code (CUKC), and a current provider key code (CPKC), a method for exchanging information with the receiving device, comprising the steps of:
generating a message, said message including a request and an accompanying authorization code required by the receiving device in order to process said request;
generating a future user key code (FUKC);
deriving a current session key code (CSKC) using said CUKC and said CPKC;
processing said identification information using said CSKC to derive a set of processed identification information; and
sending said device file name, said processed identification information, said message, and said FUKC to the receiving device.
14. In a sending device having a set of parameters stored therein including a device file name which uniquely identifies the sending device to a receiving device, a set of identification information, a current user key code (CUKC), and a current provider key code (CPKC), a method for exchanging information with the receiving device, comprising the steps of:
generating a message, said message including an instruction for the receiving device to change a current authorization code, said instruction being accompanied by said current authorization code and a new authorization code;
generating a future user key code (FUKC);
deriving a current session key code (CSKC) using said CUKC and said CPKC;
processing said identification information using said CSKC to derive a set of processed identification information; and
sending said device file name, said processed identification information, said message, and said FUKC to the receiving device.
15. In a sending device having a set of parameters stored therein including a device file name which uniquely identifies the sending device to a receiving device, a set of identification information, a current user key code (CUKC), and a current provider key code (CPKC), a method for exchanging information with the receiving device, comprising the steps of:
generating a message;
generating a future user key code (FUKC);
deriving a current session key code (CSKC) using said CUKC and said CPKC;
processing said identification information using said CSKC to derive a set of processed identification information;
sending said device file name, said processed identification information, said message, and said FUKC to the receiving device;
receiving a set of processed confirmation information from the receiving device;
deriving a second key code using said FUKC and said CPKC; and
processing said processed confirmation information using said second key code to derive a set of de-processed confirmation information.
16. The method of claim 15, further comprising the steps of:
extracting a de-processed device file name from said de-processed information;
comparing said de-processed device file name with said device file name; and
disregarding said de-processed confirmation information in response to a determination that said de-processed device file name is inconsistent with said device file name.
17. The method of claim 15, wherein said de-processed confirmation information includes a provider historical file entry and an accompanying entry designation, and wherein said method further comprises the step of:
storing said provider historical file entry and said entry designation into a provider historical file maintained in the sending device.
18. The method of claim 15, wherein said de-processed information includes a new device file name, and wherein said method further comprises the steps of:
generating a second message; and
sending at least said new device file name and said second message to the receiving device.
19. The method of claim 15, wherein said de-processed confirmation information includes a future provider key code (FPKC), and wherein said method further comprises the steps of:
generating a new message;
deriving a new key code using said FUKC and said FPKC;
processing said new message using said new key code to derive a processed new message; and
sending at least said processed new message to the receiving device.
20. In a sending device having a set of parameters stored therein including a device file name which uniquely identifies the sending device to a receiving device, a set of identification information, a current provider public code (CPPUC), and a current user private code (CUPRC), a method for exchanging information with the receiving device, comprising the steps of:
generating a message;
generating a future user key code including a future user public code (FUPUC) and a future user private code (FUPRC);
processing said identification information using said CPPUC to derive a set of processed identification information; and
sending said device file name, said processed identification information, said message, and said FUPUC to the receiving device.
21. The method of claim 20, wherein said message and said FUPUC are processed using said CPPUC before being sent to the receiving device.
22. The method of claim 21, wherein said identification information, said message, and said FUPUC are encrypted using said CPPUC as an encryption key.
23. The method of claim 22, wherein said device file name is sent to the receiving device in unencrypted form.
24. The method of claim 20, wherein said message includes a request and an accompanying authorization code required by the receiving device in order to process said request.
25. The method of claim 20, wherein said message includes an instruction for the receiving device to change a current authorization code, said instruction being accompanied by said current authorization code and a new authorization code.
26. The method of claim 20, wherein said identification information includes an entry from a provider historical file maintained in the sending device.
27. The method of claim 20, further comprising the steps of:
receiving a set of processed confirmation information from the receiving device, and
processing said processed confirmation information using said CUPRC to derive a set of de-processed confirmation information.
28. The method of claim 27, further comprising the steps of:
extracting a de-processed device file name from said de-processed information;
comparing said de-processed device file name with said device file name; and
disregarding said de-processed confirmation information in response to a determination that said de-processed device file name is inconsistent with said device file name.
29. The method of claim 27, wherein said de-processed confirmation information includes a provider historical file entry and an accompanying entry designation, and wherein said method further comprises the step of:
storing said provider historical file entry and said entry designation into a provider historical file maintained in the sending device.
30. The method of claim 27, wherein said de-processed information includes a new device file name, and wherein said method further comprises the steps of:
generating a second message; and
sending at least said new device file name and said second message to the receiving device.
31. The method of claim 27, wherein said de-processed confirmation information includes a future provider public code (FPPUC), and wherein said method further comprises the steps of:
generating a new message;
processing said new message using said FPPUC to derive a processed new message; and
sending at least said processed new message to the receiving device.
32. The method of claim 31, further comprising the steps of:
receiving a second set of processed confirmation information from the receiving device; and
processing said second set of processed confirmation information using said FUPRC to derive a second set of de-processed confirmation information.
33. A storage device for operating with a processing device having a communications interface, said storage device comprising:
a storage unit for storing a set of parameters including a device file name which uniquely identifies said storage device to a receiving device and a set of identification information;
means for causing the processing device to generate a message;
means for causing the processing device to derive a first key code from said parameters;
means for causing the processing device to process said identification information using said first key code to derive a set of processed identification information; and
means for causing the processing device to send said device file name, said processed identification information, and said message to the receiving device via the communications interface;
wherein said means for causing the processing device to generate said message comprises:
means for causing the processing device to generate a request; and
means for causing the processing device to provide an authorization code as part of said request, said authorization code being required by the receiving device to process said request.
34. A storage device for operating with a processing device having a communications interface, said storage device comprising:
a storage unit for storing a set of parameters including a device file name which uniquely identifies said storage device to a receiving device and a set of identification information;
means for causing the processing device to generate a message;
means for causing the processing device to derive a first key code from said parameters;
means for causing the processing device to process said identification information using said first key code to derive a set of processed identification information; and
means for causing the processing device to send said device file name, said processed identification information, and said message to the receiving device via the communications interface;
wherein said means for causing the processing device to generate said message comprises:
means for causing the processing device to generate an instruction for the receiving device to change a current authorization code; and
means for causing the processing device to provide said current authorization code and a new authorization code as part of said instruction.
35. A storage device for operating with a processing device having a communications interface, said storage device comprising:
a storage unit for storing a set of parameters including a device file name which uniquely identifies said storage device to a receiving device and a set of identification information;
means for causing the processing device to generate a message;
means for causing the processing device to derive a first key code from said parameters;
means for causing the processing device to process said identification information using said first key code to derive a set of processed identification information;
means for causing the processing device to send said device file name, said processed identification information, and said message to the receiving device via the communications interface;
means for causing the processing device to receive a set of processed confirmation information from the receiving device via the communications interface;
means for causing the processing device to derive a second key code different from said first key code; and
means for causing the processing device to process said processed confirmation information using said second key code to derive a set of de-processed confirmation information.
36. The storage device of claim 35, further comprising:
means for causing the processing device to extract a de-processed device file name from said de-processed information;
means for causing the processing device to compare said de-processed device file name with said device file name; and
means for causing the processing device to disregard said de-processed confirmation information in response to a determination that said de-processed device file name is inconsistent with said device file name.
37. The storage device of claim 35, wherein said de-processed confirmation information includes a provider historical file entry and an accompanying entry designation, wherein said storage device further has a provider historical file maintained thereon, and wherein said storage device further comprises:
means for causing the processing device to store said provider historical file entry and said entry designation into said provider historical file.
38. The storage device of claim 35, wherein said de-processed information includes a new device file name, and wherein said storage device further comprises:
means for causing the processing device to generate a second message; and
means for causing the processing device to send at least said new device file name and said second message to the receiving device via the communications interface.
39. The storage device of claim 35, wherein said de-processed confirmation information includes a set of new parameters, and wherein said storage device further comprises:
means for causing the processing device to generate a new message;
means for causing the processing device to derive a new key code from said new parameters;
means for causing the processing device to process said new message using said new key code to derive a processed new message; and
means for causing the processing device to send at least said processed new message to the receiving device via the communications interface.
40. The storage device of claim 35, further comprising:
means for causing the processing device to generate a new parameter; and
means for causing the processing device to send said new parameter to the receiving device via the communications interface, along with said device file name, said processed identification information, and said message.
41. The storage device of claim 40, further comprising:
means for causing the processing device to generate a new message;
means for causing the processing device to derive a new key code using said new parameter;
means for causing the processing device to process said new message using said new key code to derive a processed new message; and
means for causing the processing device to send at least said processed new message to the receiving device via the communications interface.
42. A storage device for operating with a processing device having a communications interface, said storage device comprising:
a storage unit for storing a set of parameters including a device file name which uniquely identifies said storage device to a receiving device, a set of identification information, a current user key code (CUKC), and a current provider key code (CPKC);
means for causing the processing device to generate a message;
means for causing the processing device to generate a future user key code (FUKC);
means for causing the processing device to derive a current session key code (CSKC) using said CUKC and said CPKC;
means for causing the processing device to process said identification information using said CSKC to derive a set of processed identification information; and
means for causing the processing device to send said device file name, said processed identification information, said message, and said FUKC to the receiving device via the communications interface.
43. The storage device of claim 42, further comprising:
means for causing the processing device to process said message and said FUKC using said CSKC prior to sending said message and said FUKC to the receiving device.
44. The storage device of claim 43, wherein said means for causing the processing device to process said identification information, said message, and said FUKC comprises:
means for causing the processing device to encrypt said identification information, said message, and said FUKC using said CSKC code as an encryption key.
45. The storage device of claim 42, wherein said means for causing the processing device to generate said message comprises:
means for causing the processing device to generate a request; and
means for causing the processing device to provide an authorization code as part of said request, said authorization code being required by the receiving device to process said request.
46. The storage device of claim 42, wherein said means for causing the processing device to generate said message comprises:
means for causing the processing device to generate an instruction for the receiving device to change a current authorization code; and
means for causing the processing device to provide said current authorization code and a new authorization code as part of said instruction.
47. The storage device of claim 42, wherein said storage device further has a provider historical file maintained thereon, and wherein said identification information includes an entry from said provider historical file.
48. The storage device of claim 42, further comprising:
means for causing the processing device to receive a set of processed confirmation information from the receiving device via the communications interface;
means for causing the processing device to derive a second key code using said FUKC and said CPKC; and
means for causing the processing device to process said processed confirmation information using said second key code to derive a set of de-processed confirmation information.
49. The storage device of claim 48, further comprising:
means for causing the processing device to extract a de-processed device file name from said de-processed information;
means for causing the processing device to compare said de-processed device file name with said device file name; and
means for causing the processing device to disregard said de-processed confirmation information in response to a determination that said de-processed device file name is inconsistent with said device file name.
50. The storage device of claim 48, wherein said de-processed confirmation information includes a provider historical file entry and an accompanying entry designation, wherein said storage device further has a provider historical file maintained thereon, and wherein said storage device further comprises:
means for causing the processing device to store said provider historical file entry and said entry designation into said provider historical file.
51. The storage device of claim 48, wherein said de-processed information includes a new device file name, and wherein said storage device further comprises:
means for causing the processing device to generate a second message; and
means for causing the processing device to send at least said new device file name and said second message to the receiving device via the communications interface.
52. The storage device of claim 48, wherein said de-processed confirmation information includes a future provider key code (FPKC), and wherein said storage device further comprises:
means for causing the processing device to generate a new message;
means for causing the processing device to derive a new key code using said FUKC and said FPKC;
means for causing the processing device to process said new message using said new key code to derive a processed new message; and
means for causing the processing device to send at least said processed new message to the receiving device via the communications interface.
53. A storage device for operating with a processing device having a communications interface, said storage device comprising:
a storage unit for storing a set of parameters including a device file name which uniquely identifies said storage device to a receiving device, a set of identification information, a current provider public code (CPPUC), and a current user private code (CUPRC);
means for causing the processing device to generate a message;
means for causing the processing device to generate a future user key code including a future user public code (FUPUC) and a future user private code (FUPRC);
means for causing the processing device to process said identification information using said CPPUC to derive a set of processed identification information; and
means for causing the processing device to send said device file name, said processed identification information, said message, and said FUPUC to the receiving device via the communications interface.
54. The storage device of claim 53, further comprising:
means for causing the processing device to process said message and said FUPUC using said CPPUC prior to sending said message and said FUPUC to the receiving device.
55. The storage device of claim 54, wherein said means for causing the processing device to process said identification information, said message, and said FUPUC comprises:
means for causing the processing device to encrypt said identification information, said message, and said FUPUC using said CPPUC code as an encryption key.
56. The storage device of claim 53, wherein said means for causing the processing device to generate said message comprises:
means for causing the processing device to generate a request; and
means for causing the processing device to provide an authorization code as part of said request, said authorization code being required by the receiving device to process said request.
57. The storage device of claim 53, wherein said means for causing the processing device to generate said message comprises:
means for causing the processing device to generate an instruction for the receiving device to change a current authorization code; and
means for causing the processing device to provide said current authorization code and a new authorization code as part of said instruction.
58. The storage device of claim 53, wherein said storage device further has a provider historical file maintained thereon, and wherein said identification information includes an entry from said provider historical file.
59. The storage device of claim 53, further comprising:
means for causing the processing device to receive a set of processed confirmation information from the receiving device via the communications interface; and
means for causing the processing device to process said processed confirmation information using said CUPRC to derive a set of de-processed confirmation information.
60. The storage device of claim 59, further comprising:
means for causing the processing device to extract a de-processed device file name from said de-processed information;
means for causing the processing device to compare said de-processed device file name with said device file name; and
means for causing the processing device to disregard said de-processed confirmation information in response to a determination that said de-processed device file name is inconsistent with said device file name.
61. The storage device of claim 59, wherein said de-processed confirmation information includes a provider historical file entry and an accompanying entry designation, wherein said storage device further has a provider historical file maintained thereon, and wherein said storage device further comprises:
means for causing the processing device to store said provider historical file entry and said entry designation into said provider historical file.
62. The storage device of claim 59, wherein said de-processed information includes a new device file name, and wherein said storage device further comprises:
means for causing the processing device to generate a second message; and
means for causing the processing device to send at least said new device file name and said second message to the receiving device via the communications interface.
63. The storage device of claim 59, wherein said de-processed confirmation information includes a future provider public code (FPPUC), and wherein said storage device further comprises:
means for causing the processing device to generate a new message;
means for causing the processing device to process said new message using said FPPUC to derive a processed new message; and
means for causing the processing device to send at least said processed new message to the receiving device via the communications interface.
64. The storage device of claim 63, further comprising:
means for causing the processing device to receive a second set of processed confirmation information from the receiving device; and
means for causing the processing device to process said second set of processed confirmation information using said FUPRC to derive a second set of de-processed confirmation information.
65. A communication device, comprising:
a communications interface for forming a communications link with a receiving device;
a processor coupled to said communications interface; and
a storage device coupled to said processor, said storage device comprising:
a storage unit for storing a set of parameters including a device file name which uniquely identifies said storage device to the receiving device and a set of identification information;
means for causing said processor to generate a message;
means for causing said processor to derive a first key code;
means for causing said processor to process said identification information using said first key code to derive a set of processed identification information; and
means for causing said processor to send said device file name, said processed identification information, and said message to the receiving device via said communications interface;
wherein said means for causing said processor to generate said message comprises:
means for causing said processor to generate a request; and
means for causing said processor to provide an authorization code as part of said request, said authorization code being required by the receiving device to process said request.
66. A communication device, comprising:
a communications interface for forming a communications link with a receiving device;
a processor coupled to said communications interface; and
a storage device coupled to said processor, said storage device comprising:
a storage unit for storing a set of parameters including a device file name which uniquely identifies said storage device to the receiving device and a set of identification information;
means for causing said processor to generate a message;
means for causing said processor to derive a first key code;
means for causing said processor to process said identification information using said first key code to derive a set of processed identification information;
means for causing said processor to send said device file name, said processed identification information, and said message to the receiving device via said communications interface;
means for causing said processor to generate an instruction for the receiving device to change a current authorization code; and
means for causing said processor to provide said current authorization code and a new authorization code as part of said instruction.
67. A communication device, comprising:
a communications interface for forming a communications link with a receiving device;
a processor coupled to said communications interface; and
a storage device coupled to said processor, said storage device comprising:
a storage unit for storing a set of parameters including a device file name which uniquely identifies said storage device to the receiving device and a set of identification information;
means for causing said processor to generate a message;
means for causing said processor to derive a first key code;
means for causing said processor to process said identification information using said first key code to derive a set of processed identification information;
means for causing said processor to send said device file name, said processed identification information, and said message to the receiving device via said communications interface;
means for causing said processor to receive a set of processed confirmation information from the receiving device via said communications interface;
means for causing said processor to derive a second key code different from said first key code; and
means for causing said processor to process said processed confirmation information using said second key code to derive a set of de-processed confirmation information.
68. The communication device of claim 67, wherein said storage device further comprises:
means for causing said processor to extract a de-processed device file name from said de-processed information;
means for causing said processor to compare said de-processed device file name with said device file name; and
means for causing said processor to disregard said de-processed confirmation information in response to a determination that said de-processed device file name is inconsistent with said device file name.
69. The communication device of claim 67, wherein said de-processed confirmation information includes a provider historical file entry and an accompanying entry designation, wherein said storage device further has a provider historical file maintained thereon, and wherein said storage device further comprises:
means for causing said processor to store said provider historical file entry and said entry designation into said provider historical file.
70. The communication device of claim 67, wherein said de-processed information includes a new device file name, and wherein said storage device further comprises:
means for causing said processor to generate a second message; and
means for causing said processor to send at least said new device file name and said second message to the receiving device via said communications interface.
71. The communication device of claim 67, wherein said de-processed confirmation information includes a set of new parameters, and wherein said storage device further comprises:
means for causing said processor to generate a new message;
means for causing said processor to derive a new key code from said new parameters;
means for causing said processor to process said new message using said new key code to derive a processed new message; and
means for causing said processor to send at least said processed new message to the receiving device via said communications interface.
72. A communication device, comprising:
a communications interface for forming a communications link with a receiving device;
a processor coupled to said communications interface; and
a storage device coupled to said processor, said storage device comprising:
a storage unit for storing a set of parameters including a device file name which uniquely identifies said storage device to the receiving, device and a set of identification information;
means for causing said processor to generate a message;
means for causing said processor to derive a first key code;
means for causing said processor to process said identification information using said first key code to derive a set of processed identification information;
means for causing said processor to generate a new parameter; and
means for causing said processor to send aid device file name, said processed identification information, said message, and said new parameter to the receiving device via said communications interface.
73. The communication device of claim 72, further comprising:
means for causing said processor to generate a new message;
means for causing said processor to derive a new key code using said new parameter;
means for causing said processor to process said new message using said new key code to derive a processed new message; and
means for causing said processor to send at least said processed new message to the receiving device via said communications interface.
74. A communication device, comprising:
a communications interface for forming a communications link with a receiving device;
a processor coupled to said communications interface; and
a storage device coupled to said processor, said storage device comprising:
a storage unit for storing a set of parameters including a device file name which uniquely identifies said storage device to the receiving device, a set of identification information, a current user key code (CUKC), and a current provider key code (CPKC);
means for causing said processor to generate a message;
means for causing said processor to generate a future user key code (FUKC);
means for causing said processor to derive a current session key code (CSKC) using said CUKC and said CPKC;
means for causing said processor to process said identification information using said CSKC to derive a set of processed identification information; and
means for causing said processor to send said device file name, said processed identification information, said message, and said FUKC to the receiving device via said communications interface.
75. The communication device of claim 74, wherein said storage device further comprises:
means for causing said processor to process said message and said FUKC using said CSKC prior to sending said message and said FUKC to the receiving device.
76. The communication device of claim 75, wherein said means for causing said processor to process said identification information, said message, and said FUKC comprises:
means for causing said processor to encrypt said identification information, said message, and said FUKC using said CSKC code as an encryption key.
77. The communication device of claim 74, wherein said means for causing said processor to generate said message comprises:
means for causing said processor to generate a request; and
means for causing said processor to provide an authorization code as part of said request, said authorization code being required by the receiving device to process said request.
78. The communication device of claim 74, wherein said means for causing said processor to generate said message comprises:
means for causing said processor to generate an instruction for the receiving device to change a current authorization code; and
means for causing said processor to provide said current authorization code and a new authorization code as part of said instruction.
79. The communication device of claim 74, wherein said storage device further has a provider historical file maintained thereon, and wherein said identification information includes an entry from said provider historical file.
80. The communication device of claim 74, wherein said storage device further comprises:
means for causing said processor to receive a set of processed confirmation information from the receiving device via said communications interface;
means for causing said processor to derive a second key code using said FUKC and said CPKC; and
means for causing said processor to process said processed confirmation information using said second key code to derive a set of de-processed confirmation information.
81. The communication device of claim 80, wherein said storage device further comprises:
means for causing said processor to extract a de-processed device file name from said de-processed information;
means for causing said processor to compare said de-processed device file name with said device file name; and
means for causing said processor to disregard said de-processed confirmation information in response to a determination that said de-processed device file name is inconsistent with said device file name.
82. The communication device of claim 80, wherein said de-processed confirmation information includes a provider historical file entry and an accompanying entry designation, wherein said storage device further has a provider historical file maintained thereon, and wherein said storage device further comprises:
means for causing said processor to store said provider historical file entry and said entry designation into said provider historical file.
83. The communication device of claim 80, wherein said de-processed information includes a new device file name, and wherein said storage device further comprises:
means for causing said processor to generate a second message; and
means for causing said processor to send at least said new device file name and said second message to the receiving device via said communications interface.
84. The communication device of claim 80, wherein said de-processed confirmation information includes a future provider key code (FPKC), and wherein said storage device further comprises:
means for causing said processor to generate a new message;
means for causing said processor to derive a new key code using said FUKC and said FPKC;
means for causing said processor to process said new message using said new key code to derive a processed new message; and
means for causing said processor to send at least said processed new message to the receiving device via said communications interface.
85. A communication device, comprising:
a communications interface for forming a communications link with a receiving device;
a processor coupled to said communications interface; and
a storage device coupled to said processor, said storage device comprising:
a storage unit for storing a set of parameters including a device file name which uniquely identifies said storage device to the receiving device, a set of identification information, a current provider public code (CPPUC), and a current user private code (CUPRC), said storage device
means for causing said processor to generate a message;
means for causing said processor to generate a future user key code including a future user public code (FUPUC) and a future user private code (FUPRC);
means for causing said processor to process said identification information using said CPPUC to derive a set of processed identification information; and
means for causing said processor to send said device file name, said processed identification information, said message, and said FUPUC to the receiving device via said communications interface.
86. The communication device of claim 85, wherein said storage device further comprises:
means for causing said processor to process said message and said FUPUC using said CPPUC prior to sending said message and said FUPUC to the receiving device.
87. The communication device of claim 86, wherein said means for causing said processor to process said identification information, said message, and said FUPUC comprises:
means for causing said processor to encrypt said identification information, said message, and said FUPUC using said CPPUC code as an encryption key.
88. The communication device of claim 85, wherein said means for causing said processor to generate said message comprises:
means for causing said processor to generate a request; and
means for causing said processor to provide an authorization code as part of said request, said authorization code being required by the receiving device to process said request.
89. The communication device of claim 85, wherein said means for causing said processor to generate said message comprises:
means for causing said processor to generate an instruction for the receiving device to change a current authorization code; and
means for causing said processor to provide said current authorization code and a new authorization code as part of said instruction.
90. The communication device of claim 85, wherein said storage device further has a provider historical file maintained thereon, and wherein said identification information includes an entry from said provider historical file.
91. The communication device of claim 85, wherein said storage device further comprises:
means for causing said processor to receive a set of processed confirmation information from the receiving device via said communications interface; and
means for causing said processor to process said processed confirmation information using said CUPRC to derive a set of de-processed confirmation information.
92. The communication device of claim 91, wherein said storage device further comprises:
means for causing said processor to extract a de-processed device file name from said de-processed information;
means for causing said processor to compare said de-processed device file name with said device file name; and
means for causing said processor to disregard said de-processed confirmation information in response to a determination that said de-processed device file name is inconsistent with said device file name.
93. The communication device of claim 91, wherein said de-processed confirmation information includes a provider historical file entry and an accompanying entry designation, wherein said storage device further has a provider historical file maintained thereon, and wherein said storage device further comprises:
means for causing said processor to store said provider historical file entry and said entry designation into said provider historical file.
94. The communication device of claim 91, wherein said de-processed information includes a new device file name, and wherein said storage device further comprises:
means for causing said processor to generate a second message; and
means for causing said processor to send at least said new device file name and said second message to the receiving device via said communications interface.
95. The communication device of claim 91, wherein said de-processed confirmation information includes a future provider public code (FPPUC), and wherein said storage device further comprises:
means for causing said processor to generate a new message;
means for causing said processor to process said new message using said FPPUC to derive a processed new message; and
means for causing said processor to send at least said processed new message to the receiving device via said communications interface.
96. The communication device of claim 95, wherein said storage device further comprises:
means for causing said processor to receive a second set of processed confirmation information from the receiving device; and
means for causing said processor to process said second set of processed confirmation information using said FUPRC to derive a second set of de-processed confirmation information.
97. A communication device, comprising:
a communications interface for forming a communications link with a receiving device and a sending device;
a processor coupled to said communications interface; and
a storage device coupled to said processor, said storage device comprising:
a first storage unit for storing a set of parameters including a device file name which uniquely identifies said storage device to the receiving device and a set of identification information;
a second storage unit for storing an emulation device file having a set of emulation parameters stored therein including a set of emulation reference information;
means for causing said processor to generate a message;
means for causing said processor to derive a key code;
means for causing said processor to process said identification information using said key code to derive a set of processed identification information; and
means for causing said processor to send said device file name, said processed identification information, and said message to the receiving device via said communications interface;
said storage device further comprising an emulation module, comprising:
means for causing said processor to receive, via said communications interface, an emulation device file name, a set of processed emulation identification information, and an emulation message from the sending device;
means for causing said processor to access said emulation device file using said emulation device file name as a reference;
means for causing said processor to derive an emulation key code using said emulation parameters;
means for causing said processor to process said processed emulation identification information using said emulation key code to derive a set of de-processed emulation identification information;
means for causing said processor to compare said de-processed emulation identification information with said emulation reference information; and
means for causing said processor to terminate communication with the sending device in response to a determination that said de-processed emulation identification information is inconsistent with said emulation reference information.
98. The communication device of claim 97, wherein said emulation module further comprises:
means for causing said processor to generate a set of new emulation parameters;
means for causing said processor to store said new emulation parameters into said emulation device file; and
means for causing said processor to send at least a portion of said new emulation parameters to the sending device via said communications interface.
99. A communication device, comprising:
a communications interface for forming a communications link with a receiving device and a sending device;
a processor coupled to said communications interface; and
a storage device coupled to said processor, said storage device comprising:
a first storage unit for storing a set of parameters including a device file name which uniquely identifies said storage device to the receiving device, a set of identification information, a current user key code (CUKC), and a current provider key code (CPKC);
a second storage unit for storing an emulation device file having a set of emulation parameters stored therein including a set of emulation reference information;
means for causing said processor to generate a message;
means for causing said processor to generate a future user key code (FUKC);
means for causing said processor to derive a current session key code (CSKC) using said CUKC and said CPKC;
means or causing said processor to process said identification information using said CSKC to derive a set of processed identification information; and
means for causing said processor to send said device file name, said processed identification information, said message, and said FUKC to the receiving device via said communications interface;
said storage device further comprising an emulation module, comprising:
means for causing said processor to receive, via said communications interface, an emulation device file name, a set of processed emulation identification information, and an emulation message from the sending device;
means for causing said processor to access said emulation device file using said emulation device file name as a reference;
means for causing said processor to derive an emulation key code using said emulation parameters;
means for causing said processor to process said processed emulation identification information using said emulation key code to derive a set of de-processed emulation identification information;
means for causing said processor to compare said de-processed emulation identification information with said emulation reference information; and
means for causing said processor to terminate communication with the sending device in response to a determination that said de-processed emulation identification information is inconsistent with said emulation reference information.
100. The communication device of claim 99, wherein said emulation module further comprises:
means for causing said processor to generate a set of new emulation parameters;
means for causing said processor to store said new emulation parameters into said emulation device file; and
means for causing said processor to send at least a portion of said new emulation parameters to the sending device via said communications interface.
101. A communication device, comprising:
a communications interface for forming a communications link with a receiving device and a sending device;
a processor coupled to said communications interface; and
a storage device coupled to said processor, said storage device comprising:
a first storage unit for storing a set of parameters including a device file name which uniquely identifies said storage device to the receiving device, a set of identification information, a current provider public code (CPPUC), and a current user private code (CUPRC);
a second storage unit for storing an emulation device file having a set of emulation parameters stored therein including a set of emulation reference information;
means for causing said processor to generate a message;
means for causing said processor to generate a future user key code including a future user public code (FUPUC) and a future user private code (FUPRC);
means for causing said processor to process said identification information using said CPPUC to derive a set of processed identification information; and
means for causing said processor to send said device file name, said processed identification information, said message, and said FUPUC to the receiving device via said communications interface;
said storage device further comprising an emulation module, comprising:
means for causing said processor to receive, via said communications interface, an emulation device file name, a set of processed emulation identification information, and an emulation message from the sending device;
means for causing said processor to access said emulation device file using said emulation device file name as a reference;
means for causing said processor to derive an emulation key code using said emulation parameters;
means for causing said processor to process said processed emulation identification information using said emulation key code to derive a set of de-processed emulation identification information;
means for causing said processor to compare said de-processed emulation identification information with said emulation reference information; and
means for causing said processor to terminate communication with the sending device in response to a determination that said de-processed emulation identification information is inconsistent with said emulation reference information.
102. The communication device of claim 101, wherein said emulation module further comprises:
means for causing said processor to generate a set of new emulation parameters;
means for causing said processor to store said new emulation parameters into said emulation device file; and
means for causing said processor to send at least a portion of said new emulation parameters to the sending device via said communications interface.
103. In a sending device having a set of parameters stored therein including a device file name which uniquely identifies the sending device to a receiving device and a set of identification information,said identification information including an encrypted application address (EAA) assigned to the sending device, a method for exchanging information with the receiving device, comprising the steps of:
generating a message;
retrieving said device file name and said set of identification information;
deriving a first key code from said parameters;
processing said identification information using said first key code to derive a set of processed identification information; and
sending said device file name, said processed identification information, and said message to the receiving device.
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 tier 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 representauon 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 12 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 carded 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 pan 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. 4a. 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 |
