AU776552B2

AU776552B2 - Security access and authentication token with private key transport functionality

Info

Publication number: AU776552B2
Application number: AU33605/00A
Authority: AU
Inventors: John C. Haggard; Frank Hoornaert
Original assignee: Vasco Data Security Inc
Current assignee: Onespan International GmbH
Priority date: 1999-02-10
Filing date: 2000-02-10
Publication date: 2004-09-16
Anticipated expiration: 2020-02-10
Also published as: WO2000048064A1; EP1151369A1; JP2003524928A; AU3360500A; WO2000048064A9

Description

P opscJ]605-O0 Isl isp dm-28O4/04 -1- SECURITY ACCESS AND AUTHENTICATION TOKEN WITH PRIVATE KEY TRANSPORT FUNCTIONALITY BACKGROUND OF THE INVENTION Field of the Invention This invention relates to security systems. The invention is more particularly related to the secure transfer of data, passwords, keys, and other private date, for secure transfer, user validation, authorization, etc.

The invention is directed towards security systems that can be used in combination with computers.

Discussion of Background The background of the invention deals with security tokens and the like which are used for secure operations with respect to for example, a host computer. A number of patents presently describe the state of the art concerning such security systems. By way of example only, attention is drawn to the three Cargile patents and the prior art cited therein, all of which is incorporated herein by reference.

The three Cargile patents include SOLID STATE KEY FOR CONTROLLING ACCESS TO COMPUTER SOFTWARE, U.S. Patent No.

4,599,489, SOLID STATE KEY FOR CONTROLLING ACCESS TO COMPUTER SOFTWARE, U.S. Patent No. 4,609,777, and SOLID STATE KEY FOR CONTROLLING ACCESS TO COMPUTER SYSTEMS AND TO COMPUTER SOFTWARE AND/OR FOR SECURE COMMUNICATIONS, U.S.

Patent No. 4,819,267.

The reference to any prior art in this specification is not, and should not be taken as, an acknowledgment or any form of suggestion that that prior art forms part of the common general knowledge in Australia.

P.Jp.,-3605-O0 1u sp dc.2 ,4'04 -2- SUMMARY OF THE INVENTION According to a first aspect of the present invention, there is provided a token for generating a private key transport value, comprising: a one-time password, hereinafter referenced as OTP, generator configured to produce a password each time the OTP generator is invoked; a private key, hereinafter referenced as PK, storage device configured to maintain storage of a private key; a combination device configured to combine said private key stored in said PK storage device with a password produced by said OTP generator to produce a private key transport, hereinafter referenced as PKT, encrypted in such a manner to allow the private key to be derived from the PKT; and a transport mechanism configured to communicate said PKT to a host; wherein said host can retrieve said private key from said PKT, for user by said host.

According to a second aspect of the present invention, there is provided a host device, comprising: a one-time password, hereinafter referenced as OTP, generator configured to produce a password each time the OTP generator is invoked; a private key transport, hereinafter referenced as PKT, reception mechanism configured to receive a PKT from a token device, said PKT having an encrypted private key, wherein a copy of said private key is stored at the token device; and P 'opM 3360-00 IsI doc-2I/04104 -2Aa combinatorial device configured to combine said PKT with a password generated by said OTP generator to determine the private key from said PKT, and to provide said private key to said host device, wherein said determined private key matches the private key stored on the token device.

According to a third aspect of the present invention, there is provided a method of maintaining and transmitting a private key, comprising: producing a one-time password, hereinafter referenced as

OTP;

retrieving a private key from a storage device at a token; combining said OTP and said private key to produce a private key transport, hereinafter referenced as PKT, encrypted in such a manner to allow the private key to be derived from the PKT; and transmitting said PKT from the token to a host device; wherein the host device can retrieve the private key from the PKT, for use by the host device.

According to a fourth aspect of the present invention, there is provided a method of receiving a private key, comprising the steps of: receiving at a host device an encrypted private key transport from a token device, said PKT having an encrypted private key, wherein said private key is stored at the token device; producing a one-time password, hereinafter referenced as OTP; and combining said OTP and the received encrypted private key to produce the private key, matching the private key P.po343W 3S0 It spA dmo.2SI04'O0,4 -2Bstored at the token device, and provide said private key to said host device.

According to a fifth aspect of the present invention, there is provided a system for providing secure access and authorization, comprising: a token, comprising, a private key, a private key transport, hereinafter referenced as PKT, generation device configured to generate a PKT that securely encrypts a private key, and a transport mechanism configured to communicate said PKT; and a host device comprising, a PKT reception device configured to accept said PKT value communicated to said reception device from said transport mechanism, and a decryption mechanism configured to decrypt said PKT to derive said private key; and an authorization mechanism configured to authorize any one of execution of a software program, user authentication, and access to a file, account, or other device based on the derived private key.

According to a sixth aspect of the present invention, there is provided a method for providing secure access and authorization, comprising: producing a one-time password, hereinafter referenced as OTP at a token; retrieving a private key from a storage device; combining at the token said OTP and said private key to produce a private key transport, hereinafter referenced as P ope\sc-t360S-OO IIst pl. doc.2/00404 -2C-

PKT;

transmitting said PKT value to a host; receiving the PKT at the host; producing a OTP at the host; and combining at the host said OTP and the received PKT to produce the private key.

Roughly described, the private key transport (PKT) feature allows an embodiment of the token of the invention to store an application's private encryption key and to securely "transport" the key when needed. The private encryption key is sent to an application without the encryption key being exposed to the user of the token nor is it exposed in transit to the application. Once received by a host, the private encryption key can be used to lock or unlock, encrypt or decrypt other keys and other data.

WO 00/48064 PCT/US00/03477 Environments exists where this feature greatly reduce risks associated with deploying private key based applications. The weakness in existing systems is the reliance on a user to enter his passwords to unlock or decrypt his asymmetric private keys RSA private keys) that are resident on his hard disks or floppy disks. The passwords are effectively the encryption keys that encrypt the private key when it is created and stored on the hard drive. The passwords also then decrypt, or unlock, the private key when loaded into memory for use in private key functions such as client authentication or signing of documents/transactions.

The weakness of static password is actually worse than one might first imagine. Traditional systems that rely on weak static passwords also have the ability to manage their problem by implementing password controls.

Web based private key implementations do not have the ability to manage the weakness. There is no way to force web users to change passwords, pick good ones, or help them if they have forgotten them. The browsers rely on users to select and manage the encryption keys passwords) that encrypted the private keys.

Therefore, from a security perspective despite all the advantages that private key offers, current implementations actually are a step backward.

BRIEF DESCRIPTION OF THE DRAWINGS A more complete appreciation of the invention and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when WO 00/48064 PCT/US00/03477 4 considered in connection with the accompanying drawings, wherein: Fig. 1 is a block diagram showing information flow and processes of the present invention; Fig. 2 is a diagram of a token and host processes, interactions, and information flow according to one embodiment of the present invention; and Fig. 3 is a flow chart describing processes performed of an embodiment of a token having combined C/R, R/O methods.

DESCRIPTION OF THE PREFERRED EMBODIMENTS The token of the invention is preferably a Data Encryption Standard (DES) based token device. The most powerful feature of the token is that it can support up to seven different input modes (see Table 1) that support both One Time Password (OTP) paradigms Challenge/Response and Response/Only. In addition, the token can securely transmit private keys to applications.

One Time Password Generation In order to generate a OTP all tokens must have a secret seed value stored within the token. They must also have additional information that is variable. This additional information is what is inputted to the token when the token is used to generate a OTP. The variable input can be internally and/or externally generated.

The table below identifies the seven different OTP modes of operation for the token. The table also identifies the source of the variable input given to the token for generation of the response or OTP. The challenge variable could be a value that the token WO 00/48064 PCT/US00/03477 5 receives that is used to calculate the one-time password. The time variable could be, for example, the time the token was used. The event variable could be, for example, the number of time that the token was used. Further details about OTP generation can be obtained in the above incorporated by reference Cargile patents.

Table 1 Input OTP Paradigm Source of Token Modes to Token Input Variable Challenge Challenge/Response External Challenge Event Challenge/Response Exteral Interal Challenge Time Challenge/Response Exteral Interal Challenge Event Time Challenge/Response External Interal Event Response Only Internal Event Time Response Only (RIO) Internal Time Response Only Internal All of the above modes (Table 1) use DES as a cryptographic engine for calculating the response.

Each of the modes are capable of being programmed to be compatible with various standards such as ANSI X9.9, Triple-DES, or other popular tokens.

All R/O modes simply require the user to turn the unit on and, if required, to enter their personal PIN to unlock the unit. When a PIN is required the token will prompt the user for a PIN. All C/R modes utilize an advanced optical protocol enabling the user to simply hold the device in front of their monitor to read the graphical challenge presented to them. The token has a high quality keypad for manual entry of the challenge, if the monitor is not capable of a graphical interface or the user is authenticating over a phone.

Private/Personal Key Transport WO 00/48064 PCTUS00/03477 One of the more important capabilities of the token is the Private Key Transport (PKT) feature (referred by cryptographic experts as "associative reading"). The PKT feature enables installations, or users, to assign a private key to a token for use by encryption applications. Use of the token by an encryption application never discloses the private key to anyone, including the user, except for the encryption application itself.

This is especially useful for applications that do not wish to be burdened with storing user's private keys. In addition, some installations do not even want users to know what their private keys are for encryption applications. Users mismanage their private secrets all the time and the result is the keys have to be changed periodically. If a user or installation assigns a private key to a user's token, the token can communicate the private key to an encryption application without having to disclose the private key during the communication display or through a network). Hence the need to change keys are dramatically reduced.

It is important to note that this capability applies to both DES and RSA (symmetric and asymmetric) encryption algorithms.

In order to understand the significance of this feature a brief overview on how this works is needed.

Figs. 1 and 2 depict a token working with a host system running an application that has a need to use a user's private key for encryption services. The token is capable of generating a OTP as described above.

Fig. 1 depicts the OTP feature in continuation with the WO 00/48064 PCT/US00/03477 7 PKT feature, while Fig. 2 depicts the OTP feature in a single block in order to highlight the PKT feature.

The mode used one of the seven modes of operation) to generate the OTP or Token Response is immaterial all of the modes can be used.

When an application requests that a user supply their private key for accessing encryption services, the user operates the token in the same manner as used when authenticating (as described in the three Cargile patents incorporated herein by reference). Depending upon the OTP mode of operation the user may need to input a challenge into the token. The token will generate a token response such as for example an OTP according to the mode of operation, but will perform an additional operation before displaying a response on the token screen. The operation is illustrated above as an "XOR". The OTP 50 and the user's private key are combined together (XORed) and the result is the Private Key Transport or PKT value 70. It is the PKT 70 that is displayed on the token display for the user to communicate to the host system running the encryption application. Because the internal OTP 50 is always different, the resulting PKT 70 will also always be different.

It should be noted that it is impossible to deduce the user's private key 40 with only the PKT value hence the user's private key 40 is not in danger of being disclosed if the PKT 70 is disclosed.

The Host system 101 is capable of also generating the OTP 51. This is what enables the Host system 101 to validate that a particular user is who they say they are when needing to authenticate users. In the PKT case however, the host is attempting to provide the WO 00/48064 PCT/US00/03477 8 encryption application with the user's private key and therefore uses the same "XOR" operation 61 to extract the private key 40 from the PKT 70. Once the "XOR" operation is completed, the encryption application can then use the private key for encryption services. Note that even though the PKT is always different, the private key extracted from each PKT generated is always the same, a requirement for symmetric encryption algorithms.

Once the encryption services have been completed the application simply erases the private key from memory, thereby protecting the private key from further disclosure.

An important point to note is that when using the token for generating PKTs, the secret OTP seed value does not have to be kept secret. The value can be openly distributed to any host system. This is not the case when using the token t'b authenticate user's via the token's OTP. Host systems can generate as many possible OTP's as they want, but until a physical token uses an OTP to generate a PKT, a private key cannot be generated. It should also be noted that the token can be optically programmed in the field. This feature enables the token private keys to be altered if desired.

Fig. 1 illustrates a clock 20 and seed value input to the OTP generator 10. The clock 20 may be a timepiece synchronized (within any predetermined interval) with a clock 21 at a host device.

Alternatively, the clock may take the form of any type of counting mechanism to provide a changing number for each or any set of OTP generations performed.

WO 00/48064 PCT/US00/03477 9 The problem that PKT feature solves is this How can I communicate my static private key to an encryption application without using a static value that is susceptible to being trapped? The above discussion explains how the inventive token provides the solution for this problem.

XOR Operation Token Token Private Key Host Host Private 0 Private Key Response Transport Response Key 1 1 0 1 1 1 0 1 0 1 0 1 1 1 0 0 0 0 0 0 Exclusive OR operation (XOR) does the following.

When two values are compared, if they are the same the result is a 0. If they are different the result is 1.

Since we are dealing at the lowest level possible for 0 computers the only two values possible are 0 and 1.

The following table describes all possible combinations of and exclusive or operation: 1 0 1 1 1 0 1+0=1 1+1=0 0+0=0 Therefore in the above example, I have selected a token private key of '1100' and a token response value of '1010'. If I apply an exclusive or operation on these two values I get the following result '0110', 0 which is my Private Key Transport value. This is what happens: 1 1 0 1 0 1 0 1 1 0 =0 1+0=1 0+1=1 0+0=0 WO 00/48064 PCT/US00/03477 10 This value by itself tells me nothing about the Token Private Key. '0110' in no way tells me that the real key is '1100'.

But due to the properties of the exclusive or operation, if I did this operation using the PKT and one of the original two inputs (Token Private Key and a Token Response such as an OTP) then what will be revealed is the value of the input field not used. In our case the only value that the host knows about is the Token Response (OTP) value. Therefore, the host takes the PKT value '0110' and exclusively OR's it with the host generated token response value of '1010' This is what happens: 0+1=1 1+0=1 l+l=0 0+0=0 The result of the operation is '1100' which is equal to the Token Private Key.

Fig. 3 illustrates a process flow of a token embodiment that responds to any of C/R and R/O paradigms. At step 300, the token unit is powered up.

A user inputs a password or other logon information to unlock the token (step 310). Steps 320 and 330 illustrate decision making when the token is interrogated by a system and the token determines if C/R 325 or R/O 335 processing is required. The corresponding processes are performed and the token enters a wait state 340 for further action. Upon completion of token use, the user powers down the unit (step 350).

WO 00/48064 PCT/US00/03477 11 The token includes a computing mechanism that may be initiated by a user. The following is an example of a process implemented by an initiation application resident on a token according to one embodiment of the present invention and performed by the computing mechanism. Each individual step has an associated part of the application that implements the individual step.

Diaioass Token DP700 PIN code is 12541 Digipass Application Challenge/Response First application under the T button Activation Code YMK3 1SUK Phase 1: First-Time Activation: A token application prompts the user to type the Activation Code of the selected Test Token: enter the 12-character code (see table above).

The application prompts a first Challenge: enter it in the CP/700 and copy the Token response as First Dynamic Key in the application.

The application prompts a second Challenge: enter it in the DP700 and copy the Token response as Second Dynamic Key in the application.

The two different Dynamic Keys are verified.

Both Dynamic Keys should produce the same internal secrets (referenced as SecretK2, or private key.

If no error occurred, the application will flag successful PKA Activation and create context file userfile.txt. In this file the Activation Code is stored together with the Hash Code that is derived from the SecretK2.

WO 00/48064 PCT/US00/03477 12 Phase 2: Normal Use: The application prompts a Challenge: enter it in the DP700 and copy the Token response as Dynamic Key in the application.

The Dynamic Keys is verified: if it produces an internal secret (referenced as SecretK2) that yields a Hash Code different from the stored Hash Code in context file userfile.txt, an error is generated.

If no error occurred, the application will flag successful PKA Activation.

Resetting to Phase 1: First-Time Activation: The program may be reset to its initial state of operation by removing the context file called userfile.txt.

The application provides a button 'Clear Context File' to this end. Pressing it once will delete the file.

The next time the 'Start' button is pressed, the First-time Activation phase will proceed.

Accordingly, the present invention provides for an inventive private key transport feature, and having industrial applicability in a wide range of business, security, and other technical fields for secure transmission of data, encryption codes, passwords, keys, etc. Other features, aspects and objects of the invention can be obtained from a review of the figures.

The present invention may be conveniently implemented using a conventional general purpose or a specialized digital computer or microprocessor programmed according to the teachings of the present WO 00/48064 PCT/US00/03477 13 disclosure, as will be apparent to those skilled in the computer art.

Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of application specific integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.

The present invention includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to control, or cause, a computer to perform any of the processes of the present invention. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), RAID devices, remote data storage/archive/warehousing, or any type of media or device suitable for storing instructions and/or data.

Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized*computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, and user applications. Ultimately, 14 such computer readable media further includes software for performing the present invention, as described above.

Included in the programming (software) of the general/specialized computer or microprocessor are software modules for implementing the teachings of the present invention, including, but not limited to, performing XOR operations, OTP generation, and the display, storage, or communication of results according to the processes of the present invention.

Obviously, numerous modifications and variations of the present invention are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the invention may be practiced otherwise than as specifically described herein.

Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

Claims

2. The token according to claim i, wherein said OTP generator comprises: a clock device configured to produce a clock value; a seed storage mechanism configured to store a seed value.
3. The token according to claim 2, wherein said clock device varies said clock value at a predetermined time interval.
4. The token according to claim 1, wherein said OTP generator produces a different password each time the OTP P Nopa\s 336030 lu spa doc.2SJO4O4 -16- generator is invoked. The token according to claim i, wherein said PK storage device comprises a non-volatile memory that stores said private key.
6. The token according to claim i, wherein said combinatorial device is an x-or mechanism that exclusive-ors the private key with the one time password to create the private key transport.
7. The token according to claim i, wherein said transport mechanism is an optical device that transmits an optical protocol signal allowing communication of said PKT from said token to a remote device capable of receiving said optical protocol signal.
8. The token according to claim 1, wherein said transport mechanism is a display device configured to display said PKT, thereby allowing a user to read and utilize said PKT.
9. The token according to claim 1, wherein said OTP generator is synchronized with a OTP at a host device that receives said PKT. The token according to claim i, further comprising: a private key input mechanism configured to receive a private key from any one of a user and an installer of said token; and a saving mechanism configured to save the received private key in said private key storage device. P oplsw\33605O I.u mp doc.2104I0 4 -17-
11. The token according to claim i, further comprising an input mechanism that receives an input condition that invokes said generating a private key transport value.
12. The token according to claim 11, wherein said input condition comprises any one of a challenge, event, time, and any combinations of challenge, event and time, including event and time, challenge and event, challenge and time, and challenge and event and time.
13. The token according to claim 1, wherein said generating a private key transport value is performed based on any one of an event, a time, and a combination of event and time.
14. The token according to claim 1, wherein said OTP generator is synchronized with at least one second OTP generator at a host device that receives said PKT value. A host device, comprising: a one-time password, hereinafter referenced as OTP, generator configured to produce a password each time the OTP generator is invoked; a private key transport, hereinafter referenced as PKT, reception mechanism configured to receive a PKT from a token device, said PKT having an encrypted private key, wherein a copy of said private key is stored at the token device; and a combinatorial device configured to combine said PKT with a password generated by said OTP generator to determine the private key from said PKT, and to provide said private key to said host device, wherein said determined private key matches the private key stored on the token device. P pB\scw\3360S-00 I s sp, doc.2a104'04
18- 16. The host according to claim 15, wherein said combinatorial device is an x-or mechanism configured to exclusive-or said PKT value with said OTP to determine said private key. 17. The host according to claim 15, wherein said combinatorial device is a series of x-or gates, a first input of each gate inputting one binary digit of said PKT value, and a second input of each gate inputting one binary digit of said OTP. 18. The host according to claim 15, wherein said PKT reception mechanism is an optical receiver configured to receive an optical protocol signal containing said PKT value.
19. The host according to claim 15, wherein said OTP generator produces a different password each time the OTP generator is invoked. The host according to claim 15, wherein said OTP generator is synchronized with a OTP generator associated with a token device that produces the received PKT value.
21. A method of maintaining and transmitting a private key, comprising: producing a one-time password, hereinafter referenced as OTP; retrieving a private key from a storage device at a token; combining said OTP and said private key to produce a private key transport, hereinafter referenced as PKT, P oa\se36-OO I m spa doC.2904'04 19- encrypted in such a manner to allow the private key to be derived from the PKT; and transmitting said PKT from the token to a host device; wherein the host device can retrieve the private key from the PKT, for use by the host device.
22. The method according to claim 21, wherein said step of combining comprises x-oring said OTP and said private key to produce said private key transport (PKT) value.
23. The method according to claim 21, wherein said step of producing a one time password, comprises: retrieving a seed value from a storage device; producing a clock value; and combining said clock value and said seed value to produce said OTP.
24. The method according to claim 21, further comprising the step of: synchronizing a OTP generator configured to produce said OTP with a OTP generator used to decrypt said PKT. A method of receiving a private key, comprising the steps of: receiving at a host device an encrypted private key transport from a token device, said PKT having an encrypted private key, wherein said private key is stored at the token device; producing a one-time password, hereinafter referenced as OTP; and combining said OTP and the received encrypted private key to produce the private key, matching the private key P. op\isCw360.-0 Is0 1pm do.2'04/04 stored at the token device, and provide said private key to said host device.
26. The method according to claim 25, wherein said step of combining comprises x-oring said OTP and said private key to produce said private key.
27. The method according to claim 25, wherein said step of producing a one-time password, comprises: retrieving a seed value from a storage device; producing a clock value; and combining said clock value and said seed value to produce said OTP.
28. The method according to claim 25, further comprising the step of: synchronizing a OTP generator configured to produce said OTP with a OTP generator used to produce said encrypted private key.
29. A system for providing secure access and authorization, comprising: a token, comprising, a private key, a private key transport, hereinafter referenced as PKT, generation device configured to generate a PKT that securely encrypts a private key, and a transport mechanism configured to communicate said PKT; and a host device comprising, a PKT reception device configured to accept said PKT value communicated to said reception device from said P \opo\eW) 60.O0 II Wp do.28'04'04 -21 transport mechanism, and a decryption mechanism configured to decrypt said PKT to derive said private key; and an authorization mechanism configured to authorize any one of execution of a software program, user authentication, and access to a file, account, or other device based on the derived private key. The system according to claim 29, wherein: said PKT generation device comprises a first one-time password, hereinafter referenced as OTP, generator and a forward algorithm that combines a first OTP generated by said first OTP generator with said private key to produce said PKT value; and said decryption mechanism comprises a second OTP generator and a reverse algorithm that combines a second OTP generated by said second OTP generator with said PKT value to derive said private key.
31. The system according to claim 30, wherein said forward algorithm is an x-or operation between said first OTP and said private key.
32. The system according to claim 30, wherein said reverse algorithm comprises an x-or operation between said second OTP and said PKT value.
33. The system according to claim 30, wherein: said PKT generation device includes, a seed value stored in non-volatile memory, a clock, and a combinatorial mechanism configured to combine said P op\$A33605-00 I spA doc-28/04/04 -22- seed value and a clock value from said clock to produce said first OTP; and said decryption mechanism includes, a second seed value stored in a second non- volatile memory, a second clock, and a second combinatorial mechanism configured to combine said second seed value and a second clock value from said second clock to produce said second OTP.
34. The system according to claim 33, wherein the PKT generation device clock and the decryption mechanism clock are synchronized.
35. The system according to claim 29, wherein said authorization mechanism allows transfer of data maintained in said private key to another application at said host or connected device.
36. The system according to claim 29, wherein the system includes multiple users or groups of users and any number of user accounts, invocable software programs, and/or other devices needing secure access/authentication, each of said accounts, software programs, and/or other devices being accessible at least one level by any one or more of said users.
37. The system according to claim 36, wherein each token device comprises: a OTP generator configured to produce a password each time the OTP generator is invoked; a private key storage device configured to maintain P. ops~c 33605-00 1 Spa doc.2 -23- storage of a private key; a combinatorial device configured to combine said private key stored in said private key storage device with a password produced by said OTP generator to produce said private key transport, hereinafter referenced as PKT; and a transport mechanism configured to at least one of display and communicate said PKT; wherein the private key stored in said private key storage device of any one token is associated with the user of said one token.
38. The system according to claim 36, wherein each host device comprises: a OTP generator configured to produce a password each time the OTP generator is invoked; a PKT reception mechanism configured to receive PKT value having an encrypted private key; and a combinatory device configured to combine said PKT value with a password generated by said OTP generator to derive the private key; wherein said derived private key provides access and/or authorization to any of accounts, programs, or other devices said user is authorized to access.
39. A method for providing secure access and authorization, comprising: producing a one-time password, hereinafter referenced as OTP at a token; retrieving a private key from a storage device; combining at the token said OTP and said private key to produce a private key transport, hereinafter referenced as PKT; P lopa\sc%3360-SOO I pa d c-2 4104'WO -24- transmitting said PKT value to a host; receiving the PKT at the host; producing a OTP at the host; and combining at the host said OTP and the received PKT to produce the private key. The method according to claim 39, wherein said step of combining at the sending mechanism comprises x-oring said OTP and said private key to produce said PKT and, wherein said step of combining at the reception mechanism comprises x-oring said OTP and said PKT to produce said private key.
41. The method according to claim 39, wherein said step of producing a one time password at the sending mechanism, comprises: retrieving a seed value from a storage device; producing a clock value; and combining said clock value and said seed value to produce said OTP.
42. The method according to claim 39, wherein said step of producing a one-time password at the reception mechanism, comprises: retrieving a seed value from a storage device; producing a clock value; and combining said clock value and said seed value to produce said OTP.
43. The method according to claim 39, further comprising the step of: synchronizing a OTP generator configured to produce said PKT with a OTP generator used to decrypt said PKT. P 'opa\sc33605-0 lspa doc.2J4/104
44. A token for generating a private key transport value, substantially as hereinbefore described with reference to the accompanying drawings. A host device substantially as hereinbefore described with reference to the accompanying drawings.
46. A method of maintaining and transmitting a private key, substantially as hereinbefore described with reference to the accompanying drawings.
47. A method of receiving a private key, substantially as hereinbefore described with reference to the accompanying drawings.
48. A system for providing secure access and authorization, substantially as hereinbefore described with reference to the accompanying drawings.
49. A method for providing secure access and authorization, substantially as hereinbefore described with reference to the accompanying drawings. DATED this 2 8 th day of April, 2004 Vasco Data Security, Inc. by DAVIES COLLISON CAVE Patent Attorneys for the Applicant