CA2516718A1 - Secure object for convenient identification - Google Patents
Secure object for convenient identification Download PDFInfo
- Publication number
- CA2516718A1 CA2516718A1 CA002516718A CA2516718A CA2516718A1 CA 2516718 A1 CA2516718 A1 CA 2516718A1 CA 002516718 A CA002516718 A CA 002516718A CA 2516718 A CA2516718 A CA 2516718A CA 2516718 A1 CA2516718 A1 CA 2516718A1
- Authority
- CA
- Canada
- Prior art keywords
- user
- information
- soci
- pin
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 claims abstract description 58
- 238000004364 calculation method Methods 0.000 claims abstract description 14
- 230000008859 change Effects 0.000 claims description 11
- 238000004519 manufacturing process Methods 0.000 claims description 11
- 238000013475 authorization Methods 0.000 claims description 9
- 238000004891 communication Methods 0.000 claims description 8
- 238000004422 calculation algorithm Methods 0.000 claims description 5
- 238000003825 pressing Methods 0.000 claims description 5
- 238000009826 distribution Methods 0.000 claims description 2
- 101000939500 Homo sapiens UBX domain-containing protein 11 Proteins 0.000 description 99
- 102100029645 UBX domain-containing protein 11 Human genes 0.000 description 99
- 239000003795 chemical substances by application Substances 0.000 description 43
- 238000013515 script Methods 0.000 description 10
- 238000012545 processing Methods 0.000 description 9
- 238000003860 storage Methods 0.000 description 8
- 230000004044 response Effects 0.000 description 6
- 230000006870 function Effects 0.000 description 5
- 101000720907 Pseudomonas savastanoi pv. phaseolicola Ornithine carbamoyltransferase 1, anabolic Proteins 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 238000003780 insertion Methods 0.000 description 3
- 230000037431 insertion Effects 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 238000009434 installation Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 102000040650 (ribonucleotides)n+m Human genes 0.000 description 1
- 108091032973 (ribonucleotides)n+m Proteins 0.000 description 1
- VOXZDWNPVJITMN-ZBRFXRBCSA-N 17β-estradiol Chemical compound OC1=CC=C2[C@H]3CC[C@](C)([C@H](CC4)O)[C@@H]4[C@@H]3CCC2=C1 VOXZDWNPVJITMN-ZBRFXRBCSA-N 0.000 description 1
- 244000198134 Agave sisalana Species 0.000 description 1
- 241000238631 Hexapoda Species 0.000 description 1
- NNJVILVZKWQKPM-UHFFFAOYSA-N Lidocaine Chemical compound CCN(CC)CC(=O)NC1=C(C)C=CC=C1C NNJVILVZKWQKPM-UHFFFAOYSA-N 0.000 description 1
- 241001446467 Mama Species 0.000 description 1
- 101100217298 Mus musculus Aspm gene Proteins 0.000 description 1
- JXVIIQLNUPXOII-UHFFFAOYSA-N Siduron Chemical compound CC1CCCCC1NC(=O)NC1=CC=CC=C1 JXVIIQLNUPXOII-UHFFFAOYSA-N 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 238000003556 assay Methods 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000010367 cloning Methods 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 238000005336 cracking Methods 0.000 description 1
- 238000002022 differential scanning fluorescence spectroscopy Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- DGMKFQYCZXERLX-UHFFFAOYSA-N proglumide Chemical compound CCCN(CCC)C(=O)C(CCC(O)=O)NC(=O)C1=CC=CC=C1 DGMKFQYCZXERLX-UHFFFAOYSA-N 0.000 description 1
- 239000004071 soot Substances 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/41—User authentication where a single sign-on provides access to a plurality of computers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
Abstract
A method and apparatus for automatic user authentication are described. The method includes receiving information at a device (120), the device including a credential container (200); storing the information at the credential container (200) and performing cryptographic calculations (210) on the received information and providing the encrypted information upon request (220).
Description
Sec~zre Object for Coaweniea~t ~elenti$ac~taon FIELD OF THE INVENTION
The present invention pertains to the field of secure networks and computing devices. More particularly, the present invention relates to a device for automatic user authentication.
BACKGROUND OF THE INVENTION
With rapid growth of Internet and networks, the popularity of Internet technology rises among users of network services. In order to provide secure access to network services, user names and passwords are utilized to authenticate the user logging into a system providing particular network services. Users may accesses several applicati~ns, each with its own separate aufhentication mechanism causing the user to remember multiple user narr~es and passwords. Due to thus inconvenience users usually utilize the same user name and password for multiple applications that they access. In addition; users choose easy to remember passwords, which usually are easy to crack by laackers. Cracking of one pass~rt~oa-d for an account breaches other accounts with the same user name and password. Network setups such as v~ireless Local Area Networks, remote access features, and weak intrusion protection increase vulnerability ofpasswords to technical attacks by hackers.
Many haclcers are able to trick users by posing as system administrators causing the users to voluntarily provide the haclcers.with their passwords and user names.
Due to multiple accounts and multiple passwords that users maintain, password management for system administrators becomes a tedious and sometimes burdensome task. Resetting forgotten and compromised passwords, disabling all accounts SUBSTITUTE SHEET (RULE 26) of a departing employee are examples of tasks that system administa~ators need to perform in order to manage passwords of existing accounts in the system. Inaccurate password management may lead to security breaches, such as failing to delete a password of a fired employee may allow that employee to access network areas that that employee should not be accessing anymore.
Further, even if passwords are correctly managed, using passwords correctly for authenticating users is fundamentally vulnerable to various attacks from anywhere on the Internet. One of the best ways to lower the population of potential attackers is to use a certificate-based authentication mechanism with private keys stored on physical tokens. The process of transitioning from password-based authentication to tokeaalcertificate-based authentication is a complex process. hIowever, it is a transition process that all enterprises serious about digital security need to undertake.
'~Ilaat is needed, therefore, is a solution that overcorxaes these and other shortcomings of the prior art.
SUBSTITUTE SHEET (RULE 26) ~
CA 02516718 2005-08-19 I L 1 ~ am~.wmwv i v i ' Received 28 January 2005 SUMMARY
There is disclosed a method comprising: receiving information at a device, the device including a cxedential container: storing the, information at the credential c4rrtairier; and performing cryptographic calculations on the received infomnation and providing the encrypted infom~tion upon request_ Preferably, the cryptographic calcutaGorrs are public key algorithms. tt is also preferable that the information is autfienbcation iryforTr~tion. !t is preferred that the device is a hardware device comrnunic~ting with a client computer. Pt~eferably, the device is communicating with the d'tent co~uter via a USB controtter, a Htuetooth controller, an RFlD
controller, a PCMCIA corrtrotler, or an 802_11b controller_ !t is advantageous that the credential container includes user passwords. The credential container may include cryptographic keys or digital certificates.
There is also disclosed a method comprising: encrypting a symmetric key of a first device with a public trey of a second device; transferring the encrypted symmetric key to the second device; end transferring contents of ftcst device to the second device. Preferably the contents of the first device are authentication data.
'The device may be a hardware device. The method may further comprise uploading the cvnterds of the first device to a server, downloading the contersts of the t~rst device from the server to the secorxi device, or decrypting the contents downloaded to the second device utilizing the symmetric key, There is disclosed a method comprising: receiving a request for information to be provided to a host; and determining whether the host is included in a list of trusted busts prior to pertorming cryptographic calculations on the requested information.
Preferably, the information is authentication information. The list of trusted hosts may be tocated on a hardware device, It is preferable that the cryptographic calculations inGude public key algorithms.
Another method disGosed comprises: detecting a change of a PIN by the software hosting a first device of a plurality of devices; encrypting the PIN with a public key of at least one other device from the plurality of devices; and distributing the encrypted PIN to the at least one other device from the plurality of devices. It is preferred that Amended Sheet IPEAlAU
- ' - rv.m.w~..~.,m.w.mn Received 28 January 2005 3a the frst device is a hardware device including authentication information.
Preferably, the change of the P1N is performed by a user at a user computer.
The distribution of the encrypted PlN may be performed via a server. The method may further comprise decrypting the PIN with a private key of the at least one other device from the pturafrty of devices and replacing an oki P1N with the decrypted PIN.
There is also disclosed another method comprising: receiving a challenge phrase on a client computer, inputlicx,~ the challenge phrase into a security device;
receiving a response phrase from the security device; and inputting the response phrase into the client compeer. The security device may be a hardware device including authentication information. The security device may include a display and a keyboard. tt is preferable ttaat inputting the challenge phrase into the security device is performed by a user utilizing the keyboard, n is preferable that receiving the response phrase from the searrity device comprises displaying the response phrase on the display. Preferably, the challenge phrase is a request for authentication data. The response phrase may include authentication data.
There is also anotizer method corroprising: receiving data to be dig'rtalfy signed irrito at hardware device; and digitally signing the data in the .hardware device.
The hardware device may be canftgured to be connected to a user computer. The m~e~thod may further comprise a user entering the data utilizing the hardware device keyboard and display, or a user authorizing the digital signing by utilizing physical features of the hardware device. Preferably, the physical features of the hardware device includes an authorization button. 'fhe physical features of the hardware device may include a display. k is preferable that the display displays contents to be dig'rtalty signed. The user may authorize the digital signing by pressing an authorization button.
There is disclosed an apparatus comprising: a communication controller to receive information and to transmit encrypted information; a processor to perform cryptographic calculations on received information; a credential container to store the received information; a keyboard to allow a user to control the device and a Amended Sheet IPEAIAU
' ~ ~ ' Yl. l /JIJGIlVJ/lJtlV 1 V
' ' Received 28 January 2005 3b display to display user requested information, wherein the apparatus configured to be connected to a client computer. Preferably, the apparatus is a hardware device. The apparatus may further comprise a smart card chip to perform the ayptographic calculations. The credertdal container may include a trusted hosts first comprising hosts to which the apparatus confioured to authenticate a user. The credential container may preferably include manufacturing data, wherein the manufacturing data is c~gitatly signed and stored in a cerfficate. Preferably, the manufacturing data indudes at least one piece of information from a pluraf~ty of information inducting a serial number of the apparatus, a color of the apparatus, a physical form of the apparatus, an identification of a manufacturer of the apparatus, a date of manufacturing of the apparatus.
Amended Sheet IY"EA/AU
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example and not limitation in the figures of the accompmying drawings, in which like references indicate similar elements.
Figure 1 illustrates an exemplary system architecture according to one embodiment of the invention;
Figure 2 illustrates components of a Secure Object for Convenient Identification according to one embodiment of the invention;
Figure 3 is a flow chart of a startup procedure according to one embodiment of the invention; and Figure 4 is an exemplary architecture of a processing system according to one embodiment of the invention.
SUBSTITUTE SHEET (RULE 26) DETAILED DESCRIPTION
A method and apparatus for user authentication is described. Note that in this description, references to "one embodiment" or "an embodiment" mean that the feature being referred to is included in at least one embodiment of the present invention.
Further, separate references to "one embodiment" in this description do not necessarily refer to the same embodiment; however, neither are such embodiments mutually exclusive, unless so stated and except as will be readily apparent to those sl{filled in the art. Thus, the present inventi~n can include any variety of combinations and/~r integrations of the embodiments described herein.
The present invention discloses a method and system for authenticating user via plag~sicalization ~f user credentials at a hardware device. Passwords and usernames ~f a user are stored in a hardware device arad aut~anatically pr~vided to corresponding applicati~ns that the user is attempting to access.
It will be appreciated that the tenn "playbaclc", as used herein, means a~at~r~aiically inserrCing st~red user autlaentication inf~xrnati~n int~
appr~priate applicati~ns. The term "client machine", as used herein, means a processing system hosting a Secure Dbject for Convenient Identification.
Related Technolo~y Introducti~n to related technology may be helpful in understanding some embodiments of the invention.
One embodiment of the invention utilizes Simple Object Access Protocol (SOAP). SOAP is a message-based protocol based on Extensible Markup Language SUBSTITUTE SHEET (RULE 26) (XML) for accessing services on the Web. SOAP employs XML syntax to send text commands using HTTP.
One embodiment of the invention utilizes HyperText Transfer Protocol Secure (HTTPS). HTTPS is a protocol for accessing secure Web servers. Using HTTPS
in a Uniform Resource Locator (URL) instead of HTTP directs the message to a secure port number rather than to a default port number.
One embodiment of the invention utilizes Smart Card technology. The smart card is an intelligent tolcen that provides computational capability and memory capability. The self containment of the smart card makes it resistant to attack as it does not depend on potentially vulnerable external resources. The physical structure of a smart card is specified by the International Standards Organization (ISO) 7S 10, ~~
16/1 and 7~16/~. The capability of a smart card is defined by its integrated circuit chip. Typically, the integrated C~rctagt chip consists of a microprocessor, read only memoz-y (Role, nonstatic random access memory (R.AM) and electrically erasable programmable read only n~eaxaory (~~PROI'~), which -will retain its state ~r,~hen the povJer is removed.
Another egnbodiment of the invention utilizes public-l~ey algoi-itluns.
Public-key algoritllans use two different lceys: a public lcey and a private key. The private key member of the pair must be kept private and secure. The public lcey, however, can be distributed to anyone who requests it. The public lcey of a key pair is often distributed by means of a digital cerkificate. The digital certificate is a digitally signed statement that contains information about the entity and the entity's public lcey, thus binding these two pieces of information together. A certificate is issued by a trusted organization called a Certification Authority (CA) after verification of the entity's identity. When one lcey of a SUBSTITUTE SHEET (RULE 26) Icey pair is used to encrypt a message, the other lcey from that pair is required to decrypt the message. Thus, if the user's public lcey is used to encxypt data, only a person who has the user's private key can decrypt the data. If the user's private key is used to encrypt data, then only user's public key will decrypt the data. In addition, if the private lcey is used to sign a message, the public lcey from that pair must be used to validate the signature.
Exemplary Architecture Figure 1 illustrates an exemplary architecture of the invention. An Access Agent 100 interfaces with Secure Object for Convenient Identification (SOC)]
device I20 via SOCI Application Program Intexface functions. In addition, the Access Agent 100 communicates with Identity Managerraent System (IMS) 1 I O via SOAP or I3TTPS.
IMS
is located on a ser~aer machine and communicates with a client machine that hosts the SOCI.
Figure 2 illustrates an exemplary architecture of the SOCI according to an erxab~dinmnt of flee invention. The SOCI is a hardware token capable of being connected to the user's computer. The SOCI includes a chip Crypto~lault 200, that may be a smart card chip. Tfe chip 200 includes a crypto processor 210 that performs cryptographic calculation described below. Cryptographic calculations include symmetric key, asymmetric key and hash algorithms such as ItSA, DES, 3DES, SHA1 aaad MDS, all of which are well known in the art and do not require any further explanation. In addition, the chip 200 includes NVRAM to store sensitive private data, such as private keys. The SOCI also includes Flash RAM 215 to store software drivers and non-sensitive data such as user configuration data, digital certificates, etc. The Flash RAM 215 in addition to SUBSTITUTE SHEET (RULE 26) SOCI drivers also contains software drivers to perform configuration operations sucla as installation of Access Agent on the client's computer. Part of the Flash RAM
memory is partitioned for a Smart Card File System (SCFS) interface. The RAM
may also contain a plug-n-play storage drive that appears as a disk drive on an operation system platforms supporting, for example, USB 1.1 mass-storage devices. A
Communication controller 220 is another component of the SOCI. The Communication controller 220 may be a IJSB controller, a BIuetooth controller, an RFID
controller, a PCMCIA controller, an X02.1 Ib controller, or other controller known in the art. The Communication controller provides access from the client computer, i.e. SOCI
host computer, to the Flash RAM storage 215 and the chip 200. The SOCI includes Application Interface Functions via which the client conaputer communicates with the SOCI. The Application Interface Functions provide high-level abstraction for SOCI
services, such as certificate management, data encryption/decryption, and digital signature generation. The functions exposed by the Application Programming Interface assay be implex~aented by a SOCI I~uaitime I,ibra~ (not shown). SOCI mama be wirelessl,~
connected to the client conaanuter or may be coa~aaected via a serial bus. In addition, SOCI
may communicate with servers via Local Area I~letworks (I,AI~Ts).
In one embodiment, the SOCI stores its authentication information to be provided to the Access Agent in a certificate signed by Certificate Authority (CA) trusted by the Access Agent. The Certification Authority (CA) is an entity entrusted to issue certificates assenting that the recipient individual, machine or organization requesting the certificate fulfills the conditions of an established policy. Certificates together with private keys may be utilized in SOCI to authenticate the user.
SUBSTITUTE SHEET (RULE 26) The SOCI comprises a tamper-evident casing to prevent physical access to SOCI components. In addition, the SOCI may comprise a display and a lceyboard allowing the users to control SOCI dir ectly without utilizing the computer.
During manufacturing, information about particular SOCI,device is recorded in the NVR.A.M of the device. Information includes a serial number of the device, a color of the device, a physical form of the device, identification of the manufacturer and the date of manufacturing, etc. These infonnation is stored as digitally signed attributes in a certificate signed~by the CA ti-usted by the Access Agent. When the Access Agent registers the device with a server, verification of ownership of the.
certificate is performed by ensuring that the signature on the device certificate is digitally signed by the CA
trusted to issue device certificates.
The phi=sisal processing platf~rnas that embody the Access Agent and IIi~S
may include processing systems, such as conventional personal computers (T.'Cs) and/or server-class computer systems according to various embodiments of the invention. Figure G illustrates ara e~~ample of such a processing systenx at a high Level. T'he processing system of Figure 4~ includes one or more processors 400, read-only memory (IZ~1~J,) 410, random access memory (12AM) 420, and a mass storage device 430 coupled to each other on a bus system 440. The bus system 440 includes one or more buses, which may be cornzected to each other through various bridges, controllers andlor adapters, which are well lcnown in the art. For example, the bus system 440 may include a 'system bus', which may be co~mected through an adapter to one or more expansion, such as a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. Also coupled to the bus system 440 are a the mass storage SUBSTITUTE SHEET (RULE 26) device 430, one or more input/output (I/O) devices 450 and one or more data communication devices 460 to communicate with remote processing systems via one or more communication linl~s 465 and 470, respectively. The I/O devices 450 may include, for example, airy one or more of a display device, a keyboard, a pointing device (e.g., mouse, touchpad, traclcball), an audio spealcer.
The processors) 400 may include one or more conventional general-piupose or special-purpose programmable microprocessors, digital signal processors (DSFs), application specific integrated circuits (ASICs), or programmable logic devices (FLD), or a combination of such devices. The mass storage device 430 may include any one or more devices suitable for storing large volumes of data in a non-volatile manner, such as naagnetic disk or tape, magneto-optical storage device, or any of various types ~f Digital video Disk (DVD) or Compact Disk (CD) based storage or a combination of such devices.
The data communication devices) 460 each may be any devices suitable for enabling the processing systen~a to comrnua~icate, data with a remote processing systeaa~
over a data comannunicati~n liable, such as a Wireless transceiver or a conventional telephone modean, a Wireless modem, an Integrated Services Digital Network (ISD1~1) adapter, a Digital Subscriber Line (DSL) modem, a cable modem, a satellite transceiver, an Ethem:et adapter, or the like.
Methodolo~:y With theses concepts in milid embodiments of the invention can be further explored.
S~a~up ~'~-~ce~8u~re SUBSTITUTE SHEET (RULE 26) In order for a user to be automatically authenticated for each application that the user attempts to access, the Access.Agent 100 can be executing on the user's machine, i.e. client machine. The startup procedure will be described with reference to Figure 3. At 310 the Access Agent 1.00 is executed upon the boot up of the client machine. The Access Agent 100 interacts with a logon procedure of the operating system to handle initialization procedures. Upon initialization, the Access Agent 100 at 320 starts a thread, which may poll ports, for example USB ports, of the client machine. The polling thread identifies whether SOCI is present in any of the ports. If the polling thread does not identify the SOCI, the Access Agent at 325 prompts the user to insect the SOCI
and awaits for the insertion of the SOCI by periodically polling the ports. If the polling thread identifies that SOCI is already connected to the port or if the new SOCI has been inserted, the session management module 230 displays a. dialogue box prompting the user for a personal identification number (PIN). Upon the user entering the PI1~T, the Access Agent at 335 verifies the entered PIN. If the PIN is successfully verified, the Access Agent 100 obtains the operating systeam login a~ad pass~rord infoa~x~ation of the user at 54=0. For example, if the client machine is running Windows Operating System, the Access Agent 100 obtains Windows L,ogin ID and Windows Password. In one .
embodiment the operating system login identification and password data are encrypted and stoxed in the SOCI and retrieved by the Access Agent 100 via SOCI APIs.
The user may have several operating system login identifications and passwords and in this case the user may be presented with a pull down menu to select the login ID and password for the current session. At 345 upon determining and decrypting the login ID and password, SUBSTITUTE SHEET (RULE 26) the Access Agent 100 inserts the ID and password into the operating system logon procedure.
S~CI Initialization In one embodiment upon insertion of the SOCI, a setup program located in the flash memory of the SOCI is executed to determine whethex the Access Agent 100 is installed on the client machine. If the Access Agent is not installed on the client machine, the setup program locates the download server to download the Access Agent installer module. The setup program may contain a default location of the installer module. If the setup program fails to locate the installer for download, the setup program prompts the user for location of the installer or for an insertion of a diskette or CD-ROM
including the installer module. Upon installation of the installer, the user is prompted to enter a SOCI
personal identification number (PlIV) and password. PII~ of the SOCI is distributed with the SOCI. User can change the PIN after obtaining access to the SOCI upon entering the original PIIV. Upon the user entering the PIN and password, the installer transmits the PIl 1 and pass°~v~rd data t~ the II~S. In on a enabodin~ent data transmitted to the IT'~1S
includes SOCI identification number retrieved from the SOCI device, SOCI
properties, SOCI public keys, encrypted Common Symmetric I~ey (CSI). Upon receiving the data, the IMS creates a new user account and registers the SOCI with the account.
The IMS
generates a new certificate and transmits the certificate to the Access Agent which stores the certificate in the SOCI. The IMS may also encrypt the CSI with a key derived from the SOCI password and ful-ther encrypt the CSK with the IMS's public ltey. In one embodiment, the sewer's public lcey is stored on a separate secure server, or stored in a hardware l~ey device.
SUBSTITUTE SHEET (RULE 26) ~
Automated Authentlcatbon In one embodiment the Access Agent 100 executes in the backgr ound at the client machine and identifies user's login, logout, change of password activities and records the procedures in a form of an access script. The access scripts are encrypted and stored in the SOCI and the IMS server. The Access Agent 100 captures operating system messages for various applications and identifies whether any of the captured messages comprise user authentication data. If the Access Agent 100 identifies the user authentication application data for a particular application, the Access Agent 100 stores the information in the SOCI. Upon identifying the user authentication application, the Access Agent 100 generates access scripts to be played back when the user attempts to access an application requiring authentication inforrgaatioaa. When the user attempts to .
access the application, the Access Agent 100 determines ~wlaether an access script egoists for the application. If the access script exists, the authentication inforrraation is injected into the login procedure of the application. If the access script does not exist, the Access Agent 100 captures the Iog~a~ a~af~nlaatl~ax entered by the user and stores the encrypted information in the SOOI and IMS. An access script is an AML-based sca~ipt that contains information on how to playback authentication information, such as the location of the application in the computer, the name of.the application, the buttons to click, etc. An example of an access script is provided below:
<.AceessScript .4SP~i~zt="expl~rer. exe ">
<ASll~letl~od .llletlzodNat~~e= "explorer. exe-1 " Met7zodType= "login ">
<ASStep . . ID= "1 "> <ASResult>
<WebSigr~ature> <PageURL> <lPage URL>
< Uses FieldName><lUserFieldName>
<PwdFieldNatne>
<lPwdFieldNaf~ze>
<Aetiof~FieldNa~aze> <lActior~FieldNaf~ae> <IYT~ebSignatuf°e>
SUBSTITUTE SHEET (RULE 26) ~
< WndSignature> < WrrdIDl>
<Wi~dTitle>Co~anect to<lWr~dTitle><SenJerLabel> <lServerLabel>< Usef NanaeLabel> User r~ame: <lUserNameLabel><PassmordLabel>Pass~~ord: <lPass~~'ordLabel><New PasswordLabel> <lNewPass~t~o~°a'Label> < ver~PassN'ordLabel > <l hey°~Passwo rdLabel><LeftStr>Connect to<lLeftStr><RightSt~~><lRightStr><SefmerDlgIDI><UserNameDIgIDI><New PasswordDlgIDl> < OkButtonlDl> <lWizdSighature> <ASEvent. > <Message> </M
essage> <lASEverzt> </,qSResult> <lASStep> <lASMethod> <lAccessSc~°ipt>
In addition, the access script contains information allowing the Access Agent 100 to recognize access points of an application, the class identification of the application, password policies associated with the application, etc.
In one embodiment upon identification of user's authentication data, the Access Agent 100 converts the user's authentication data into a stronger form of authentication data to be then presented to 'the applications that user attempts to access.
The con~rersion of the authentication data may be perfomled without the user being aware of the change. The Access Agent I 00 can generate a longer password by adding alpha-nunlea~c characters unto the password, for e~arnple to tlae end of the user's password. The Access ~a.gent 100 can also generate a randoim password to be utilized for user authentication purposes instead of the user's chosen password to ensure higher security levels. The new password is generated based on configurable criteria, such as the minimal Iength, or the inclusion of special characters. In addition, the stronger form of authentication data can be digital certificates, private keys, etc. The request for change of passwords to the application can be performed by either Access Agent or IMS.
This is .
done by supplying both the old password and the new password to the application. Once the application accepts the change and is aware of the new password, Access Agent will store the new password in the form of configuration data encrypted by the CSI.
The SUBSTITUTE SHEET (RULE 26) Access Agent 100 may also request IMS for a digital certificate using a private key stoxed in the SOCI. This stronger form can be used for user authentication purposes instead of user's password if the application is configured to use public lcey authentication mechanism. Once again, the.procedure of conversion ofuser's password into a staronger form of authentication credentials may be performed without lcnowledge of the user. By configuring the Access Agent to periodically and automatically perform the above procedures, user credentials will be more secured, hence they are fortified.
Data Synchronization In one embodiment the user authentication data and access scripts are stored in SOCI and on the IMS server for a baclcup. The data in the SOCI and IMS server is identical, unless during one of the update sessions by Access Agent 100, the server was not accessible due for e~~ample, to laclt of network connection between the client machine and the IMS server. Also, the data on the server may be updated when the user utilizes a duplicate SOCI, causing the original SOCI not to have the latest copy of the user authentication data. In one emla~d~nlent, all the records stored in flee SOCT
and TI~~S
server are time stamped allowing the Access Agent 100 to determine whether SOOT or IMS server includes the latest data. Upon detenniiung the location of the latest user authentication data, the Access Agent 100 directs SOCI or IMS to update the data to ensure identical copies of user authentication data on SOCI and IMS server.
In one embodiment, the user authentication data may be stored on the client machine as software. If a SOCI device is not available, the user may request the stored authentication data from the TMS server. Upon downloading the user SUBSTITUTE SHEET (RULE 26) authentication information to the client machine, the downloaded data may be used by the Access Agent in a manner described above.
Secure SOCI Authentication In one embodiment of the invention SOCI will authenticate itself only to servers included in the trusted host list stored in SOCI. To prevent tampering with the list, the list is stored in SOCI rather than on the user's computer that is typically not secured. The trusted host list contains servers that user is attempting to access using public key algorithm authentication mechanism, such as IIVIS server.
Restricting the .
servers to which SOCI can authenticate may prevent a form of "man-in-the-riaiddle"
attaclcs, which occurs when a client authenticates to a malicious server, allowing the malicious server to masquerade as tIae client to a legitimate server by forwarding the responses to any challenges given by the legitimate server. Thus, prior to performing any cryptographic calculations described in this specification, SOCI ensures that a server that is being accessed by the user is on the trusted host list.
~~~F~ ~'~TT'~T I~ai~trrll~~tl~n Each SOCI is assigned a persoiaal identification number (hIN) at the time of manufacturing. In order for the user to unlock SOCI for the first time, the user has to use the assigned PIN. However, the PIN can be changed by the user at a later time. In acase that the user utilizes multiple SOCIs, it is advantageous that all SOCIs are assigned the same PIN to simplify SOCI login procedure for the user. In one embodiment of the invention, the Access Agent 100 detects a change in SOCI PIN perfoizned by the client.
The Access Agent 100 encrypts the new PIN with the public keys of all SOCIs of the SUBSTITUTE SHEET (RULE 26) user and distributes the encrypted PIN to the SOCIs utilizing IMS server. SOCI
devices decrypt the PIN with the private key and update their data to reflect the new PIN.
It will be appreciated that tlae same method may be employed to ensure that all SOCI's utilized by the user are updated upon the_user changing user authentication information for different applications.
Public/Private Key Authentication As described above, in one embodiment of the invention, SOCIs include public-private key pairs to be registered with a Certificate Authority of IMS.
°Tlae issued certificate and key pair are stored in the SOCI. When the Access Agent detects an application that has been configured to employ public keys for user authentication, the Access Agent directs the SOCI to perform crypto function to aut~matically cause the application to provide the user with the access. °Tlae private key is stored in the SOCI and is not provided to any application or any user. ~'lae SOCI has playsical tamper-proof features to ensure that private keys are not released. In one enabodinaent the private key gnat' be bua~aed into the chip of SOCIs durang naanufact~.~riaag.
In one embodiment administrators of IhflS may cause the authentication system to utilize private-public key method without the system users being aware of tlae change. I7ue to automatic user authentication, the users need not be aware of the authentication method employed as long as tlaey are provided with the desired application access.
Cloning of SOCI
In one embodiment, a SOCI device can be "cloned", such that tlae second SOCI can functionally authenticate to the same set of applications as the original SOCI.
SUBSTITUTE SHEET (RULE 26) A SOCI includes a symmetric Icey, which is used to encrypt the contents of SOCI. To "clone" a SOCI in a secure manner, the original SOCI encrypts its symmetric lcey using the public key of the second SOCI and transfers the encrypted symmetric Icey and the encrypted contents of the original SOCI to the second SOCI via a server, which may be the IIVIS server. The second SOCI downloads the encrypted CSI. Once the encryption Icey is acquired by the new SOCI, the encrypted authentication data is downloaded from the server to the new SOCI to is decrypted utilizing the encryption Icey. The new SOCI is therefore able to access the same information as the original SOCI, and is said to host a cloned credential container.
Manual authorization of S~CI for performing digital signature In one embodiment, a SOCI device includes a physical feature such as a button that allo~m7s a user to manually input 1]is/laer authorization of SOCT
performing digital signature operations. The SOCT device will only perform digital signature operations when the button is pressed, thus preventing generation of digital signature ~rifihout lm~~~ledge of the user, f~r ea~anlple by a malicious program located on the SOCT's host machine. The user can press the authorization button when he/she is trying to authenticate him/herself.
In another embodiment, SOCI has a display that displays the message to inform the user what information SOCI is about to digitally sigai upon user pressing the authorization button. This allows the user to lcnow what he/she is authorizing. For example, a bank transaction will display "Transferring $10 to account # 1234"
on the SOCI display before the user can authorize the transaction by pressing the authorization button on the device.
SUBSTITUTE SHEET (RULE 26) Exterxaal S~C~ Coaatr~1 In one embodiment of the invention, the user may utilize SOCI keyboard and display to digitally sign data without utilizing a computer. In order to digitally sign data, such as a text message, a user inputs the message into SOCI utilizing the keys of the keyboard. The user then verifies the accuracy of the entered message on the display and requests the digital signature of the entered message by pressing one of the keyboard buttons. -The user may also utilize SOCI to obtain hislher authentication information to be provided to an application that the user attempts to access without connecting SOCI to the user's computer. Upon receiving a prompt for authentication inf~ranati~ra, i.e. challenge phrase, at the user's c~mputer, tlae user enters tlae request for the prompted information into the S~~I using S~CI keyboard. Upon retrieving the requested information, SOCI displays the data on its display, which then the user may manually enter at the user's computer.
Thus, a. rrzethod and apparatus for user authentication have beeaa described.
Although the present invention has been described with reference t~ specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without depai-ting.from the broader spirit and scope of the invention as set forth in the claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense.
SUBSTITUTE SHEET (RULE 26)
The present invention pertains to the field of secure networks and computing devices. More particularly, the present invention relates to a device for automatic user authentication.
BACKGROUND OF THE INVENTION
With rapid growth of Internet and networks, the popularity of Internet technology rises among users of network services. In order to provide secure access to network services, user names and passwords are utilized to authenticate the user logging into a system providing particular network services. Users may accesses several applicati~ns, each with its own separate aufhentication mechanism causing the user to remember multiple user narr~es and passwords. Due to thus inconvenience users usually utilize the same user name and password for multiple applications that they access. In addition; users choose easy to remember passwords, which usually are easy to crack by laackers. Cracking of one pass~rt~oa-d for an account breaches other accounts with the same user name and password. Network setups such as v~ireless Local Area Networks, remote access features, and weak intrusion protection increase vulnerability ofpasswords to technical attacks by hackers.
Many haclcers are able to trick users by posing as system administrators causing the users to voluntarily provide the haclcers.with their passwords and user names.
Due to multiple accounts and multiple passwords that users maintain, password management for system administrators becomes a tedious and sometimes burdensome task. Resetting forgotten and compromised passwords, disabling all accounts SUBSTITUTE SHEET (RULE 26) of a departing employee are examples of tasks that system administa~ators need to perform in order to manage passwords of existing accounts in the system. Inaccurate password management may lead to security breaches, such as failing to delete a password of a fired employee may allow that employee to access network areas that that employee should not be accessing anymore.
Further, even if passwords are correctly managed, using passwords correctly for authenticating users is fundamentally vulnerable to various attacks from anywhere on the Internet. One of the best ways to lower the population of potential attackers is to use a certificate-based authentication mechanism with private keys stored on physical tokens. The process of transitioning from password-based authentication to tokeaalcertificate-based authentication is a complex process. hIowever, it is a transition process that all enterprises serious about digital security need to undertake.
'~Ilaat is needed, therefore, is a solution that overcorxaes these and other shortcomings of the prior art.
SUBSTITUTE SHEET (RULE 26) ~
CA 02516718 2005-08-19 I L 1 ~ am~.wmwv i v i ' Received 28 January 2005 SUMMARY
There is disclosed a method comprising: receiving information at a device, the device including a cxedential container: storing the, information at the credential c4rrtairier; and performing cryptographic calculations on the received infomnation and providing the encrypted infom~tion upon request_ Preferably, the cryptographic calcutaGorrs are public key algorithms. tt is also preferable that the information is autfienbcation iryforTr~tion. !t is preferred that the device is a hardware device comrnunic~ting with a client computer. Pt~eferably, the device is communicating with the d'tent co~uter via a USB controtter, a Htuetooth controller, an RFlD
controller, a PCMCIA corrtrotler, or an 802_11b controller_ !t is advantageous that the credential container includes user passwords. The credential container may include cryptographic keys or digital certificates.
There is also disclosed a method comprising: encrypting a symmetric key of a first device with a public trey of a second device; transferring the encrypted symmetric key to the second device; end transferring contents of ftcst device to the second device. Preferably the contents of the first device are authentication data.
'The device may be a hardware device. The method may further comprise uploading the cvnterds of the first device to a server, downloading the contersts of the t~rst device from the server to the secorxi device, or decrypting the contents downloaded to the second device utilizing the symmetric key, There is disclosed a method comprising: receiving a request for information to be provided to a host; and determining whether the host is included in a list of trusted busts prior to pertorming cryptographic calculations on the requested information.
Preferably, the information is authentication information. The list of trusted hosts may be tocated on a hardware device, It is preferable that the cryptographic calculations inGude public key algorithms.
Another method disGosed comprises: detecting a change of a PIN by the software hosting a first device of a plurality of devices; encrypting the PIN with a public key of at least one other device from the plurality of devices; and distributing the encrypted PIN to the at least one other device from the plurality of devices. It is preferred that Amended Sheet IPEAlAU
- ' - rv.m.w~..~.,m.w.mn Received 28 January 2005 3a the frst device is a hardware device including authentication information.
Preferably, the change of the P1N is performed by a user at a user computer.
The distribution of the encrypted PlN may be performed via a server. The method may further comprise decrypting the PIN with a private key of the at least one other device from the pturafrty of devices and replacing an oki P1N with the decrypted PIN.
There is also disclosed another method comprising: receiving a challenge phrase on a client computer, inputlicx,~ the challenge phrase into a security device;
receiving a response phrase from the security device; and inputting the response phrase into the client compeer. The security device may be a hardware device including authentication information. The security device may include a display and a keyboard. tt is preferable ttaat inputting the challenge phrase into the security device is performed by a user utilizing the keyboard, n is preferable that receiving the response phrase from the searrity device comprises displaying the response phrase on the display. Preferably, the challenge phrase is a request for authentication data. The response phrase may include authentication data.
There is also anotizer method corroprising: receiving data to be dig'rtalfy signed irrito at hardware device; and digitally signing the data in the .hardware device.
The hardware device may be canftgured to be connected to a user computer. The m~e~thod may further comprise a user entering the data utilizing the hardware device keyboard and display, or a user authorizing the digital signing by utilizing physical features of the hardware device. Preferably, the physical features of the hardware device includes an authorization button. 'fhe physical features of the hardware device may include a display. k is preferable that the display displays contents to be dig'rtalty signed. The user may authorize the digital signing by pressing an authorization button.
There is disclosed an apparatus comprising: a communication controller to receive information and to transmit encrypted information; a processor to perform cryptographic calculations on received information; a credential container to store the received information; a keyboard to allow a user to control the device and a Amended Sheet IPEAIAU
' ~ ~ ' Yl. l /JIJGIlVJ/lJtlV 1 V
' ' Received 28 January 2005 3b display to display user requested information, wherein the apparatus configured to be connected to a client computer. Preferably, the apparatus is a hardware device. The apparatus may further comprise a smart card chip to perform the ayptographic calculations. The credertdal container may include a trusted hosts first comprising hosts to which the apparatus confioured to authenticate a user. The credential container may preferably include manufacturing data, wherein the manufacturing data is c~gitatly signed and stored in a cerfficate. Preferably, the manufacturing data indudes at least one piece of information from a pluraf~ty of information inducting a serial number of the apparatus, a color of the apparatus, a physical form of the apparatus, an identification of a manufacturer of the apparatus, a date of manufacturing of the apparatus.
Amended Sheet IY"EA/AU
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example and not limitation in the figures of the accompmying drawings, in which like references indicate similar elements.
Figure 1 illustrates an exemplary system architecture according to one embodiment of the invention;
Figure 2 illustrates components of a Secure Object for Convenient Identification according to one embodiment of the invention;
Figure 3 is a flow chart of a startup procedure according to one embodiment of the invention; and Figure 4 is an exemplary architecture of a processing system according to one embodiment of the invention.
SUBSTITUTE SHEET (RULE 26) DETAILED DESCRIPTION
A method and apparatus for user authentication is described. Note that in this description, references to "one embodiment" or "an embodiment" mean that the feature being referred to is included in at least one embodiment of the present invention.
Further, separate references to "one embodiment" in this description do not necessarily refer to the same embodiment; however, neither are such embodiments mutually exclusive, unless so stated and except as will be readily apparent to those sl{filled in the art. Thus, the present inventi~n can include any variety of combinations and/~r integrations of the embodiments described herein.
The present invention discloses a method and system for authenticating user via plag~sicalization ~f user credentials at a hardware device. Passwords and usernames ~f a user are stored in a hardware device arad aut~anatically pr~vided to corresponding applicati~ns that the user is attempting to access.
It will be appreciated that the tenn "playbaclc", as used herein, means a~at~r~aiically inserrCing st~red user autlaentication inf~xrnati~n int~
appr~priate applicati~ns. The term "client machine", as used herein, means a processing system hosting a Secure Dbject for Convenient Identification.
Related Technolo~y Introducti~n to related technology may be helpful in understanding some embodiments of the invention.
One embodiment of the invention utilizes Simple Object Access Protocol (SOAP). SOAP is a message-based protocol based on Extensible Markup Language SUBSTITUTE SHEET (RULE 26) (XML) for accessing services on the Web. SOAP employs XML syntax to send text commands using HTTP.
One embodiment of the invention utilizes HyperText Transfer Protocol Secure (HTTPS). HTTPS is a protocol for accessing secure Web servers. Using HTTPS
in a Uniform Resource Locator (URL) instead of HTTP directs the message to a secure port number rather than to a default port number.
One embodiment of the invention utilizes Smart Card technology. The smart card is an intelligent tolcen that provides computational capability and memory capability. The self containment of the smart card makes it resistant to attack as it does not depend on potentially vulnerable external resources. The physical structure of a smart card is specified by the International Standards Organization (ISO) 7S 10, ~~
16/1 and 7~16/~. The capability of a smart card is defined by its integrated circuit chip. Typically, the integrated C~rctagt chip consists of a microprocessor, read only memoz-y (Role, nonstatic random access memory (R.AM) and electrically erasable programmable read only n~eaxaory (~~PROI'~), which -will retain its state ~r,~hen the povJer is removed.
Another egnbodiment of the invention utilizes public-l~ey algoi-itluns.
Public-key algoritllans use two different lceys: a public lcey and a private key. The private key member of the pair must be kept private and secure. The public lcey, however, can be distributed to anyone who requests it. The public lcey of a key pair is often distributed by means of a digital cerkificate. The digital certificate is a digitally signed statement that contains information about the entity and the entity's public lcey, thus binding these two pieces of information together. A certificate is issued by a trusted organization called a Certification Authority (CA) after verification of the entity's identity. When one lcey of a SUBSTITUTE SHEET (RULE 26) Icey pair is used to encrypt a message, the other lcey from that pair is required to decrypt the message. Thus, if the user's public lcey is used to encxypt data, only a person who has the user's private key can decrypt the data. If the user's private key is used to encrypt data, then only user's public key will decrypt the data. In addition, if the private lcey is used to sign a message, the public lcey from that pair must be used to validate the signature.
Exemplary Architecture Figure 1 illustrates an exemplary architecture of the invention. An Access Agent 100 interfaces with Secure Object for Convenient Identification (SOC)]
device I20 via SOCI Application Program Intexface functions. In addition, the Access Agent 100 communicates with Identity Managerraent System (IMS) 1 I O via SOAP or I3TTPS.
IMS
is located on a ser~aer machine and communicates with a client machine that hosts the SOCI.
Figure 2 illustrates an exemplary architecture of the SOCI according to an erxab~dinmnt of flee invention. The SOCI is a hardware token capable of being connected to the user's computer. The SOCI includes a chip Crypto~lault 200, that may be a smart card chip. Tfe chip 200 includes a crypto processor 210 that performs cryptographic calculation described below. Cryptographic calculations include symmetric key, asymmetric key and hash algorithms such as ItSA, DES, 3DES, SHA1 aaad MDS, all of which are well known in the art and do not require any further explanation. In addition, the chip 200 includes NVRAM to store sensitive private data, such as private keys. The SOCI also includes Flash RAM 215 to store software drivers and non-sensitive data such as user configuration data, digital certificates, etc. The Flash RAM 215 in addition to SUBSTITUTE SHEET (RULE 26) SOCI drivers also contains software drivers to perform configuration operations sucla as installation of Access Agent on the client's computer. Part of the Flash RAM
memory is partitioned for a Smart Card File System (SCFS) interface. The RAM
may also contain a plug-n-play storage drive that appears as a disk drive on an operation system platforms supporting, for example, USB 1.1 mass-storage devices. A
Communication controller 220 is another component of the SOCI. The Communication controller 220 may be a IJSB controller, a BIuetooth controller, an RFID
controller, a PCMCIA controller, an X02.1 Ib controller, or other controller known in the art. The Communication controller provides access from the client computer, i.e. SOCI
host computer, to the Flash RAM storage 215 and the chip 200. The SOCI includes Application Interface Functions via which the client conaputer communicates with the SOCI. The Application Interface Functions provide high-level abstraction for SOCI
services, such as certificate management, data encryption/decryption, and digital signature generation. The functions exposed by the Application Programming Interface assay be implex~aented by a SOCI I~uaitime I,ibra~ (not shown). SOCI mama be wirelessl,~
connected to the client conaanuter or may be coa~aaected via a serial bus. In addition, SOCI
may communicate with servers via Local Area I~letworks (I,AI~Ts).
In one embodiment, the SOCI stores its authentication information to be provided to the Access Agent in a certificate signed by Certificate Authority (CA) trusted by the Access Agent. The Certification Authority (CA) is an entity entrusted to issue certificates assenting that the recipient individual, machine or organization requesting the certificate fulfills the conditions of an established policy. Certificates together with private keys may be utilized in SOCI to authenticate the user.
SUBSTITUTE SHEET (RULE 26) The SOCI comprises a tamper-evident casing to prevent physical access to SOCI components. In addition, the SOCI may comprise a display and a lceyboard allowing the users to control SOCI dir ectly without utilizing the computer.
During manufacturing, information about particular SOCI,device is recorded in the NVR.A.M of the device. Information includes a serial number of the device, a color of the device, a physical form of the device, identification of the manufacturer and the date of manufacturing, etc. These infonnation is stored as digitally signed attributes in a certificate signed~by the CA ti-usted by the Access Agent. When the Access Agent registers the device with a server, verification of ownership of the.
certificate is performed by ensuring that the signature on the device certificate is digitally signed by the CA
trusted to issue device certificates.
The phi=sisal processing platf~rnas that embody the Access Agent and IIi~S
may include processing systems, such as conventional personal computers (T.'Cs) and/or server-class computer systems according to various embodiments of the invention. Figure G illustrates ara e~~ample of such a processing systenx at a high Level. T'he processing system of Figure 4~ includes one or more processors 400, read-only memory (IZ~1~J,) 410, random access memory (12AM) 420, and a mass storage device 430 coupled to each other on a bus system 440. The bus system 440 includes one or more buses, which may be cornzected to each other through various bridges, controllers andlor adapters, which are well lcnown in the art. For example, the bus system 440 may include a 'system bus', which may be co~mected through an adapter to one or more expansion, such as a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. Also coupled to the bus system 440 are a the mass storage SUBSTITUTE SHEET (RULE 26) device 430, one or more input/output (I/O) devices 450 and one or more data communication devices 460 to communicate with remote processing systems via one or more communication linl~s 465 and 470, respectively. The I/O devices 450 may include, for example, airy one or more of a display device, a keyboard, a pointing device (e.g., mouse, touchpad, traclcball), an audio spealcer.
The processors) 400 may include one or more conventional general-piupose or special-purpose programmable microprocessors, digital signal processors (DSFs), application specific integrated circuits (ASICs), or programmable logic devices (FLD), or a combination of such devices. The mass storage device 430 may include any one or more devices suitable for storing large volumes of data in a non-volatile manner, such as naagnetic disk or tape, magneto-optical storage device, or any of various types ~f Digital video Disk (DVD) or Compact Disk (CD) based storage or a combination of such devices.
The data communication devices) 460 each may be any devices suitable for enabling the processing systen~a to comrnua~icate, data with a remote processing systeaa~
over a data comannunicati~n liable, such as a Wireless transceiver or a conventional telephone modean, a Wireless modem, an Integrated Services Digital Network (ISD1~1) adapter, a Digital Subscriber Line (DSL) modem, a cable modem, a satellite transceiver, an Ethem:et adapter, or the like.
Methodolo~:y With theses concepts in milid embodiments of the invention can be further explored.
S~a~up ~'~-~ce~8u~re SUBSTITUTE SHEET (RULE 26) In order for a user to be automatically authenticated for each application that the user attempts to access, the Access.Agent 100 can be executing on the user's machine, i.e. client machine. The startup procedure will be described with reference to Figure 3. At 310 the Access Agent 1.00 is executed upon the boot up of the client machine. The Access Agent 100 interacts with a logon procedure of the operating system to handle initialization procedures. Upon initialization, the Access Agent 100 at 320 starts a thread, which may poll ports, for example USB ports, of the client machine. The polling thread identifies whether SOCI is present in any of the ports. If the polling thread does not identify the SOCI, the Access Agent at 325 prompts the user to insect the SOCI
and awaits for the insertion of the SOCI by periodically polling the ports. If the polling thread identifies that SOCI is already connected to the port or if the new SOCI has been inserted, the session management module 230 displays a. dialogue box prompting the user for a personal identification number (PIN). Upon the user entering the PI1~T, the Access Agent at 335 verifies the entered PIN. If the PIN is successfully verified, the Access Agent 100 obtains the operating systeam login a~ad pass~rord infoa~x~ation of the user at 54=0. For example, if the client machine is running Windows Operating System, the Access Agent 100 obtains Windows L,ogin ID and Windows Password. In one .
embodiment the operating system login identification and password data are encrypted and stoxed in the SOCI and retrieved by the Access Agent 100 via SOCI APIs.
The user may have several operating system login identifications and passwords and in this case the user may be presented with a pull down menu to select the login ID and password for the current session. At 345 upon determining and decrypting the login ID and password, SUBSTITUTE SHEET (RULE 26) the Access Agent 100 inserts the ID and password into the operating system logon procedure.
S~CI Initialization In one embodiment upon insertion of the SOCI, a setup program located in the flash memory of the SOCI is executed to determine whethex the Access Agent 100 is installed on the client machine. If the Access Agent is not installed on the client machine, the setup program locates the download server to download the Access Agent installer module. The setup program may contain a default location of the installer module. If the setup program fails to locate the installer for download, the setup program prompts the user for location of the installer or for an insertion of a diskette or CD-ROM
including the installer module. Upon installation of the installer, the user is prompted to enter a SOCI
personal identification number (PlIV) and password. PII~ of the SOCI is distributed with the SOCI. User can change the PIN after obtaining access to the SOCI upon entering the original PIIV. Upon the user entering the PIN and password, the installer transmits the PIl 1 and pass°~v~rd data t~ the II~S. In on a enabodin~ent data transmitted to the IT'~1S
includes SOCI identification number retrieved from the SOCI device, SOCI
properties, SOCI public keys, encrypted Common Symmetric I~ey (CSI). Upon receiving the data, the IMS creates a new user account and registers the SOCI with the account.
The IMS
generates a new certificate and transmits the certificate to the Access Agent which stores the certificate in the SOCI. The IMS may also encrypt the CSI with a key derived from the SOCI password and ful-ther encrypt the CSK with the IMS's public ltey. In one embodiment, the sewer's public lcey is stored on a separate secure server, or stored in a hardware l~ey device.
SUBSTITUTE SHEET (RULE 26) ~
Automated Authentlcatbon In one embodiment the Access Agent 100 executes in the backgr ound at the client machine and identifies user's login, logout, change of password activities and records the procedures in a form of an access script. The access scripts are encrypted and stored in the SOCI and the IMS server. The Access Agent 100 captures operating system messages for various applications and identifies whether any of the captured messages comprise user authentication data. If the Access Agent 100 identifies the user authentication application data for a particular application, the Access Agent 100 stores the information in the SOCI. Upon identifying the user authentication application, the Access Agent 100 generates access scripts to be played back when the user attempts to access an application requiring authentication inforrgaatioaa. When the user attempts to .
access the application, the Access Agent 100 determines ~wlaether an access script egoists for the application. If the access script exists, the authentication inforrraation is injected into the login procedure of the application. If the access script does not exist, the Access Agent 100 captures the Iog~a~ a~af~nlaatl~ax entered by the user and stores the encrypted information in the SOOI and IMS. An access script is an AML-based sca~ipt that contains information on how to playback authentication information, such as the location of the application in the computer, the name of.the application, the buttons to click, etc. An example of an access script is provided below:
<.AceessScript .4SP~i~zt="expl~rer. exe ">
<ASll~letl~od .llletlzodNat~~e= "explorer. exe-1 " Met7zodType= "login ">
<ASStep . . ID= "1 "> <ASResult>
<WebSigr~ature> <PageURL> <lPage URL>
< Uses FieldName><lUserFieldName>
<PwdFieldNatne>
<lPwdFieldNaf~ze>
<Aetiof~FieldNa~aze> <lActior~FieldNaf~ae> <IYT~ebSignatuf°e>
SUBSTITUTE SHEET (RULE 26) ~
< WndSignature> < WrrdIDl>
<Wi~dTitle>Co~anect to<lWr~dTitle><SenJerLabel> <lServerLabel>< Usef NanaeLabel> User r~ame: <lUserNameLabel><PassmordLabel>Pass~~ord: <lPass~~'ordLabel><New PasswordLabel> <lNewPass~t~o~°a'Label> < ver~PassN'ordLabel > <l hey°~Passwo rdLabel><LeftStr>Connect to<lLeftStr><RightSt~~><lRightStr><SefmerDlgIDI><UserNameDIgIDI><New PasswordDlgIDl> < OkButtonlDl> <lWizdSighature> <ASEvent. > <Message> </M
essage> <lASEverzt> </,qSResult> <lASStep> <lASMethod> <lAccessSc~°ipt>
In addition, the access script contains information allowing the Access Agent 100 to recognize access points of an application, the class identification of the application, password policies associated with the application, etc.
In one embodiment upon identification of user's authentication data, the Access Agent 100 converts the user's authentication data into a stronger form of authentication data to be then presented to 'the applications that user attempts to access.
The con~rersion of the authentication data may be perfomled without the user being aware of the change. The Access Agent I 00 can generate a longer password by adding alpha-nunlea~c characters unto the password, for e~arnple to tlae end of the user's password. The Access ~a.gent 100 can also generate a randoim password to be utilized for user authentication purposes instead of the user's chosen password to ensure higher security levels. The new password is generated based on configurable criteria, such as the minimal Iength, or the inclusion of special characters. In addition, the stronger form of authentication data can be digital certificates, private keys, etc. The request for change of passwords to the application can be performed by either Access Agent or IMS.
This is .
done by supplying both the old password and the new password to the application. Once the application accepts the change and is aware of the new password, Access Agent will store the new password in the form of configuration data encrypted by the CSI.
The SUBSTITUTE SHEET (RULE 26) Access Agent 100 may also request IMS for a digital certificate using a private key stoxed in the SOCI. This stronger form can be used for user authentication purposes instead of user's password if the application is configured to use public lcey authentication mechanism. Once again, the.procedure of conversion ofuser's password into a staronger form of authentication credentials may be performed without lcnowledge of the user. By configuring the Access Agent to periodically and automatically perform the above procedures, user credentials will be more secured, hence they are fortified.
Data Synchronization In one embodiment the user authentication data and access scripts are stored in SOCI and on the IMS server for a baclcup. The data in the SOCI and IMS server is identical, unless during one of the update sessions by Access Agent 100, the server was not accessible due for e~~ample, to laclt of network connection between the client machine and the IMS server. Also, the data on the server may be updated when the user utilizes a duplicate SOCI, causing the original SOCI not to have the latest copy of the user authentication data. In one emla~d~nlent, all the records stored in flee SOCT
and TI~~S
server are time stamped allowing the Access Agent 100 to determine whether SOOT or IMS server includes the latest data. Upon detenniiung the location of the latest user authentication data, the Access Agent 100 directs SOCI or IMS to update the data to ensure identical copies of user authentication data on SOCI and IMS server.
In one embodiment, the user authentication data may be stored on the client machine as software. If a SOCI device is not available, the user may request the stored authentication data from the TMS server. Upon downloading the user SUBSTITUTE SHEET (RULE 26) authentication information to the client machine, the downloaded data may be used by the Access Agent in a manner described above.
Secure SOCI Authentication In one embodiment of the invention SOCI will authenticate itself only to servers included in the trusted host list stored in SOCI. To prevent tampering with the list, the list is stored in SOCI rather than on the user's computer that is typically not secured. The trusted host list contains servers that user is attempting to access using public key algorithm authentication mechanism, such as IIVIS server.
Restricting the .
servers to which SOCI can authenticate may prevent a form of "man-in-the-riaiddle"
attaclcs, which occurs when a client authenticates to a malicious server, allowing the malicious server to masquerade as tIae client to a legitimate server by forwarding the responses to any challenges given by the legitimate server. Thus, prior to performing any cryptographic calculations described in this specification, SOCI ensures that a server that is being accessed by the user is on the trusted host list.
~~~F~ ~'~TT'~T I~ai~trrll~~tl~n Each SOCI is assigned a persoiaal identification number (hIN) at the time of manufacturing. In order for the user to unlock SOCI for the first time, the user has to use the assigned PIN. However, the PIN can be changed by the user at a later time. In acase that the user utilizes multiple SOCIs, it is advantageous that all SOCIs are assigned the same PIN to simplify SOCI login procedure for the user. In one embodiment of the invention, the Access Agent 100 detects a change in SOCI PIN perfoizned by the client.
The Access Agent 100 encrypts the new PIN with the public keys of all SOCIs of the SUBSTITUTE SHEET (RULE 26) user and distributes the encrypted PIN to the SOCIs utilizing IMS server. SOCI
devices decrypt the PIN with the private key and update their data to reflect the new PIN.
It will be appreciated that tlae same method may be employed to ensure that all SOCI's utilized by the user are updated upon the_user changing user authentication information for different applications.
Public/Private Key Authentication As described above, in one embodiment of the invention, SOCIs include public-private key pairs to be registered with a Certificate Authority of IMS.
°Tlae issued certificate and key pair are stored in the SOCI. When the Access Agent detects an application that has been configured to employ public keys for user authentication, the Access Agent directs the SOCI to perform crypto function to aut~matically cause the application to provide the user with the access. °Tlae private key is stored in the SOCI and is not provided to any application or any user. ~'lae SOCI has playsical tamper-proof features to ensure that private keys are not released. In one enabodinaent the private key gnat' be bua~aed into the chip of SOCIs durang naanufact~.~riaag.
In one embodiment administrators of IhflS may cause the authentication system to utilize private-public key method without the system users being aware of tlae change. I7ue to automatic user authentication, the users need not be aware of the authentication method employed as long as tlaey are provided with the desired application access.
Cloning of SOCI
In one embodiment, a SOCI device can be "cloned", such that tlae second SOCI can functionally authenticate to the same set of applications as the original SOCI.
SUBSTITUTE SHEET (RULE 26) A SOCI includes a symmetric Icey, which is used to encrypt the contents of SOCI. To "clone" a SOCI in a secure manner, the original SOCI encrypts its symmetric lcey using the public key of the second SOCI and transfers the encrypted symmetric Icey and the encrypted contents of the original SOCI to the second SOCI via a server, which may be the IIVIS server. The second SOCI downloads the encrypted CSI. Once the encryption Icey is acquired by the new SOCI, the encrypted authentication data is downloaded from the server to the new SOCI to is decrypted utilizing the encryption Icey. The new SOCI is therefore able to access the same information as the original SOCI, and is said to host a cloned credential container.
Manual authorization of S~CI for performing digital signature In one embodiment, a SOCI device includes a physical feature such as a button that allo~m7s a user to manually input 1]is/laer authorization of SOCT
performing digital signature operations. The SOCT device will only perform digital signature operations when the button is pressed, thus preventing generation of digital signature ~rifihout lm~~~ledge of the user, f~r ea~anlple by a malicious program located on the SOCT's host machine. The user can press the authorization button when he/she is trying to authenticate him/herself.
In another embodiment, SOCI has a display that displays the message to inform the user what information SOCI is about to digitally sigai upon user pressing the authorization button. This allows the user to lcnow what he/she is authorizing. For example, a bank transaction will display "Transferring $10 to account # 1234"
on the SOCI display before the user can authorize the transaction by pressing the authorization button on the device.
SUBSTITUTE SHEET (RULE 26) Exterxaal S~C~ Coaatr~1 In one embodiment of the invention, the user may utilize SOCI keyboard and display to digitally sign data without utilizing a computer. In order to digitally sign data, such as a text message, a user inputs the message into SOCI utilizing the keys of the keyboard. The user then verifies the accuracy of the entered message on the display and requests the digital signature of the entered message by pressing one of the keyboard buttons. -The user may also utilize SOCI to obtain hislher authentication information to be provided to an application that the user attempts to access without connecting SOCI to the user's computer. Upon receiving a prompt for authentication inf~ranati~ra, i.e. challenge phrase, at the user's c~mputer, tlae user enters tlae request for the prompted information into the S~~I using S~CI keyboard. Upon retrieving the requested information, SOCI displays the data on its display, which then the user may manually enter at the user's computer.
Thus, a. rrzethod and apparatus for user authentication have beeaa described.
Although the present invention has been described with reference t~ specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without depai-ting.from the broader spirit and scope of the invention as set forth in the claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense.
SUBSTITUTE SHEET (RULE 26)
Claims (35)
1. A method for automatic user authentication, the method comprising:
receiving information at a certificate-based Secure Object for Convenient Identification (SOCI) device, the device including a credential container;
storing the information of the credential container; and performing cryptographic calculations on the received information and providing the encrypted information upon request, wherein the cryptographic calculations are public key algorithms.
receiving information at a certificate-based Secure Object for Convenient Identification (SOCI) device, the device including a credential container;
storing the information of the credential container; and performing cryptographic calculations on the received information and providing the encrypted information upon request, wherein the cryptographic calculations are public key algorithms.
2. The method of claim 1 wherein the information is authentication information.
3. The method of claim 1 wherein the device is a hardware device communicating with a client computer.
4. The method of claim 3 wherein the device is communicating with the client computer via a USB controller,
5. The method of claim 3 wherein the device is communicating with the client computer via a Bluetooth controller.
6. The method of claim 3 wherein the device is communicating with the client computer via an RFID controller.
7. The method of claim 3 wherein the device is communicating with the client computer via a PCMCIA controller.
8. The method of claim 3 wherein the device is communicating with the client computer via an 802.11b controller.
9. The method of claim 1 wherein the credential container includes user passwords.
10. The method of claim 1 wherein the credential container includes cryptographic keys.
11. The method of claim 1 wherein the credential container includes digital certificates.
12. The method according to claim 1, further comprising:
encrypting a symmetric key of the device with a public key of another certificate-based Secure Object for Convenient Identification (SOCI) device;
transferring the encrypted symmetric key to the another device; and transferring content of the device to the another device.
encrypting a symmetric key of the device with a public key of another certificate-based Secure Object for Convenient Identification (SOCI) device;
transferring the encrypted symmetric key to the another device; and transferring content of the device to the another device.
13. The method of claim 12 wherein the content of the device are authentication data.
14. The method of claim 12 wherein the another device is a hardware device.
15. The method of claim 12 further comprising uploading the content of the device to a server.
16. The method of claim 15 further comprising downloading the content of the device from the server to the another device.
17. The method of claim 16 further comprising decrypting the content downloaded to the another device utilizing the symmetric key.
18. The method according to claim 1, further comprising:
receiving a request for information to be provided to a host; and determining whether the host is included in a list of trusted hosts prior to performing cryptographic calculations on the requested information.
receiving a request for information to be provided to a host; and determining whether the host is included in a list of trusted hosts prior to performing cryptographic calculations on the requested information.
19. The method according to claim 1, further comprising:
detecting a change of a PIN by the software hosting the device;
encrypting the PIN with a public key of at least another device;
distributing the encrypted PIN to the at least another device.
detecting a change of a PIN by the software hosting the device;
encrypting the PIN with a public key of at least another device;
distributing the encrypted PIN to the at least another device.
20. The method of claim 19 wherein the change of the PIN is performed by a user at a user computer.
21. The method of claim 19 wherein the distribution of the encrypted PIN is performed via a server.
22. The method of claim 19 further comprising decrypting the PIN with a private key of the at least another device and replacing an old PIN with the decrypted PIN.
23. The method according to claim 1 comprising:
receiving data to be digitally signed into the device;
digitally signing the data in the device.
receiving data to be digitally signed into the device;
digitally signing the data in the device.
24. The method of claim 23 wherein the device is configured to be connected to a user computer.
25. The method of claim 23 further comprising a user authorizing the digital signing by utilizing physical features of the device.
26. The method of claim 25 wherein the physical features of the device include an authorization button.
27. The method of claim 25 wherein the physical features of the device include a display.
28. The method of claim 27 wherein the display displays content to be digitally signed.
29. The method of claim 25 wherein the user authorizing the digital signing by pressing an authorization button.
30. An apparatus far automatic user authentication, the apparatus comprising:
a communication controller of a certificate-based Secure Object for Convenient Identification (SOCI) device, the controller receiving information and transmitting encrypted information;
a processor to perform cryptographic calculations on received information;
a credential container to store the received information;
a keyboard to allow a user to control the device and a display to display user requested information, wherein the apparatus configured to be connected to a client computer.
a communication controller of a certificate-based Secure Object for Convenient Identification (SOCI) device, the controller receiving information and transmitting encrypted information;
a processor to perform cryptographic calculations on received information;
a credential container to store the received information;
a keyboard to allow a user to control the device and a display to display user requested information, wherein the apparatus configured to be connected to a client computer.
31. The apparatus of claim 30 wherein the apparatus is a hardware device.
32. The apparatus of claim 30 further comprising a smart card chip to perform the cryptographic calculations.
33. The apparatus of claim 30 wherein the credential container includes a trusted hosts list comprising hosts to which the apparatus is configured to authenticate a user.
34. The apparatus of claim 30 wherein the credential container includes manufacturing data, wherein the manufacturing data is digitally signed and stored in a certificate.
35. The apparatus of claim 34, wherein the manufacturing data includes at least one piece of information from a plurality of information including a serial number of the apparatus, a color of the apparatus, a physical form of the apparatus, an identification of a manufacturer of the apparatus, a date of manufacturing of the apparatus.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| SG200301114-5 | 2003-03-03 | ||
| SG200301114 | 2003-03-03 | ||
| PCT/SG2003/000107 WO2004079988A1 (en) | 2003-03-03 | 2003-05-07 | Secure object for convenient identification |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2516718A1 true CA2516718A1 (en) | 2004-09-16 |
Family
ID=32923969
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002516718A Abandoned CA2516718A1 (en) | 2003-03-03 | 2003-05-07 | Secure object for convenient identification |
Country Status (5)
| Country | Link |
|---|---|
| US (3) | US20040177258A1 (en) |
| EP (1) | EP1606914A4 (en) |
| AU (1) | AU2003223153A1 (en) |
| CA (1) | CA2516718A1 (en) |
| WO (1) | WO2004079988A1 (en) |
Families Citing this family (41)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002351569A (en) * | 2001-03-21 | 2002-12-06 | Toshiba Corp | Method and system for managing software license and storage medium |
| US20040177258A1 (en) * | 2003-03-03 | 2004-09-09 | Ong Peng T. | Secure object for convenient identification |
| EP1480107A3 (en) * | 2003-05-16 | 2006-05-24 | Berner Fachhochschule Hochschule für Technik und Architektur Biel | Method for authentication of a user with an authorizing device, and a security apparatus for carrying out the method |
| US7467417B2 (en) * | 2003-06-18 | 2008-12-16 | Architecture Technology Corporation | Active verification of boot firmware |
| CN100401280C (en) * | 2005-06-08 | 2008-07-09 | 北京飞天诚信科技有限公司 | Universal serial bus data transmission method and apparatus thereof |
| US8438647B2 (en) * | 2005-07-14 | 2013-05-07 | Imation Corp. | Recovery of encrypted data from a secure storage device |
| US8335920B2 (en) * | 2005-07-14 | 2012-12-18 | Imation Corp. | Recovery of data access for a locked secure storage device |
| US8321953B2 (en) * | 2005-07-14 | 2012-11-27 | Imation Corp. | Secure storage device with offline code entry |
| US8015606B1 (en) | 2005-07-14 | 2011-09-06 | Ironkey, Inc. | Storage device with website trust indication |
| US8505075B2 (en) * | 2005-07-14 | 2013-08-06 | Marble Security, Inc. | Enterprise device recovery |
| US20070067620A1 (en) * | 2005-09-06 | 2007-03-22 | Ironkey, Inc. | Systems and methods for third-party authentication |
| WO2007030517A2 (en) * | 2005-09-06 | 2007-03-15 | Ironkey, Inc. | Systems and methods for third-party authentication |
| US8266378B1 (en) | 2005-12-22 | 2012-09-11 | Imation Corp. | Storage device with accessible partitions |
| US8639873B1 (en) | 2005-12-22 | 2014-01-28 | Imation Corp. | Detachable storage device with RAM cache |
| US7912762B2 (en) * | 2006-03-31 | 2011-03-22 | Amazon Technologies, Inc. | Customizable sign-on service |
| CN100454321C (en) * | 2006-04-29 | 2009-01-21 | 北京飞天诚信科技有限公司 | USB device with data memory and intelligent secret key and control method thereof |
| US20070300031A1 (en) * | 2006-06-22 | 2007-12-27 | Ironkey, Inc. | Memory data shredder |
| JP4895731B2 (en) * | 2006-09-05 | 2012-03-14 | 株式会社リコー | Information processing device, peripheral device, and program |
| JP5129499B2 (en) * | 2007-04-11 | 2013-01-30 | キヤノン株式会社 | Image forming apparatus, image forming apparatus control method, program, and storage medium |
| US20090089366A1 (en) * | 2007-09-27 | 2009-04-02 | Kalman Csaba Toth | Portable caching system |
| US8694776B2 (en) * | 2007-12-21 | 2014-04-08 | Spansion Llc | Authenticated memory and controller slave |
| JP5468557B2 (en) * | 2008-02-27 | 2014-04-09 | フィッシャー−ローズマウント システムズ インコーポレイテッド | Wireless device join key supply |
| US8683088B2 (en) | 2009-08-06 | 2014-03-25 | Imation Corp. | Peripheral device data integrity |
| US8745365B2 (en) * | 2009-08-06 | 2014-06-03 | Imation Corp. | Method and system for secure booting a computer by booting a first operating system from a secure peripheral device and launching a second operating system stored a secure area in the secure peripheral device on the first operating system |
| GB201000288D0 (en) * | 2010-01-11 | 2010-02-24 | Scentrics Information Security | System and method of enforcing a computer policy |
| US10250589B2 (en) * | 2010-05-20 | 2019-04-02 | Cyberark Software Ltd. | System and method for protecting access to authentication systems |
| US8499157B1 (en) * | 2010-09-29 | 2013-07-30 | Emc Corporation | Device-based password management |
| US9582505B2 (en) * | 2011-03-24 | 2017-02-28 | Echostar Technologies L.L.C. | Handling user-specific information for content during content-altering operations |
| KR101803305B1 (en) * | 2011-12-15 | 2018-01-10 | 삼성전자주식회사 | Dispaly apparatus and method for operating application |
| US8572685B2 (en) * | 2012-01-06 | 2013-10-29 | Timothy J. Caplis | Consolidated data services apparatus and method |
| US8677121B2 (en) | 2012-07-31 | 2014-03-18 | Hewlett-Packard Development Company, L.P. | Monitoring encrypted session properties |
| GB2507596B (en) | 2012-10-30 | 2014-09-17 | Barclays Bank Plc | Secure computing device and method |
| GB2507497B (en) | 2012-10-30 | 2015-01-14 | Barclays Bank Plc | Device and method for secure memory access |
| US9430624B1 (en) * | 2013-04-30 | 2016-08-30 | United Services Automobile Association (Usaa) | Efficient logon |
| US9509676B1 (en) * | 2013-04-30 | 2016-11-29 | United Services Automobile Association (Usaa) | Efficient startup and logon |
| US9438560B2 (en) * | 2014-12-31 | 2016-09-06 | Symantec Corporation | Systems and methods for automatically applying firewall policies within data center applications |
| CN104794626B (en) * | 2015-04-28 | 2018-09-11 | 广东欧珀移动通信有限公司 | A kind of method for anti-counterfeit and device based on hardware information |
| CN105072136B (en) * | 2015-09-06 | 2018-02-09 | 李宏仲 | A kind of equipment room safety certifying method and system based on virtual drive |
| DE102016209543A1 (en) * | 2016-06-01 | 2017-12-07 | Bundesdruckerei Gmbh | User authentication using an ID token |
| US10747900B1 (en) * | 2019-08-19 | 2020-08-18 | Cyberark Software Ltd. | Discovering and controlling sensitive data available in temporary access memory |
| CN112507301B (en) * | 2020-12-05 | 2021-10-08 | 广州技象科技有限公司 | Internet of things equipment control method, device, equipment and storage medium |
Family Cites Families (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US18569A (en) * | 1857-11-10 | Device fob pobming bound tenons on window-blind slats | ||
| US169961A (en) * | 1875-11-16 | Improvement in dumping-wagons | ||
| US1876A (en) * | 1840-12-01 | Sled for the transportation oe ice in blocks | ||
| US5774551A (en) * | 1995-08-07 | 1998-06-30 | Sun Microsystems, Inc. | Pluggable account management interface with unified login and logout and multiple user authentication services |
| US5943423A (en) * | 1995-12-15 | 1999-08-24 | Entegrity Solutions Corporation | Smart token system for secure electronic transactions and identification |
| CA2261262C (en) * | 1996-07-22 | 2007-08-21 | Cyva Research Corporation | Personal information security and exchange tool |
| US6704871B1 (en) * | 1997-09-16 | 2004-03-09 | Safenet, Inc. | Cryptographic co-processor |
| US6170065B1 (en) * | 1997-11-14 | 2001-01-02 | E-Parcel, Llc | Automatic system for dynamic diagnosis and repair of computer configurations |
| JPH11154137A (en) * | 1997-11-20 | 1999-06-08 | Hitachi Ltd | Individual work environment setting system |
| US6185685B1 (en) * | 1997-12-11 | 2001-02-06 | International Business Machines Corporation | Security method and system for persistent storage and communications on computer network systems and computer network systems employing the same |
| US6460138B1 (en) * | 1998-10-05 | 2002-10-01 | Flashpoint Technology, Inc. | User authentication for portable electronic devices using asymmetrical cryptography |
| CA2255285C (en) * | 1998-12-04 | 2009-10-13 | Certicom Corp. | Enhanced subscriber authentication protocol |
| US7272723B1 (en) * | 1999-01-15 | 2007-09-18 | Safenet, Inc. | USB-compliant personal key with integral input and output devices |
| KR20000006645A (en) * | 1999-08-30 | 2000-02-07 | 김종률 | Multi-account Management System for Computer Network using a Integrated Circuit Card and Method Therof |
| FR2802666B1 (en) * | 1999-12-17 | 2002-04-05 | Activcard | COMPUTER SYSTEM FOR ACCREDITATION ACCESS APPLICATION |
| US6601020B1 (en) * | 2000-05-03 | 2003-07-29 | Eureka Software Solutions, Inc. | System load testing coordination over a network |
| US7552333B2 (en) * | 2000-08-04 | 2009-06-23 | First Data Corporation | Trusted authentication digital signature (tads) system |
| GB0023969D0 (en) * | 2000-09-30 | 2000-11-15 | Internet Extra Ltd | Mechanism for automating the extraction of selected information from web based pages design and implementation |
| GB2370474B (en) * | 2000-12-22 | 2004-06-09 | Hewlett Packard Co | Communicating credentials across a network |
| FI115098B (en) * | 2000-12-27 | 2005-02-28 | Nokia Corp | Authentication in data communication |
| US7039027B2 (en) * | 2000-12-28 | 2006-05-02 | Symbol Technologies, Inc. | Automatic and seamless vertical roaming between wireless local area network (WLAN) and wireless wide area network (WWAN) while maintaining an active voice or streaming data connection: systems, methods and program products |
| US7069433B1 (en) * | 2001-02-20 | 2006-06-27 | At&T Corp. | Mobile host using a virtual single account client and server system for network access and management |
| US7921290B2 (en) * | 2001-04-18 | 2011-04-05 | Ipass Inc. | Method and system for securely authenticating network access credentials for users |
| US6986047B2 (en) * | 2001-05-10 | 2006-01-10 | International Business Machines Corporation | Method and apparatus for serving content from a semi-trusted server |
| WO2002095553A2 (en) * | 2001-05-18 | 2002-11-28 | Imprivata Inc. | Biometric authentication for remote initiation of actions and services |
| US20030143372A1 (en) * | 2002-01-28 | 2003-07-31 | Beverly Richard | Antibacterial toilet tissue |
| JP2005518011A (en) * | 2002-02-14 | 2005-06-16 | ペッシン，ザッカリー | Apparatus and method for decentralized capital system |
| US8745409B2 (en) * | 2002-12-18 | 2014-06-03 | Sandisk Il Ltd. | System and method for securing portable data |
| US20040177258A1 (en) | 2003-03-03 | 2004-09-09 | Ong Peng T. | Secure object for convenient identification |
-
2003
- 2003-04-21 US US10/420,676 patent/US20040177258A1/en not_active Abandoned
- 2003-05-07 EP EP03719281A patent/EP1606914A4/en not_active Withdrawn
- 2003-05-07 WO PCT/SG2003/000107 patent/WO2004079988A1/en not_active Application Discontinuation
- 2003-05-07 AU AU2003223153A patent/AU2003223153A1/en not_active Abandoned
- 2003-05-07 CA CA002516718A patent/CA2516718A1/en not_active Abandoned
-
2007
- 2007-02-20 US US11/708,795 patent/US7581099B2/en not_active Expired - Fee Related
-
2009
- 2009-02-02 US US12/363,988 patent/US8850558B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| WO2004079988A1 (en) | 2004-09-16 |
| EP1606914A4 (en) | 2008-12-31 |
| EP1606914A1 (en) | 2005-12-21 |
| US20090205030A1 (en) | 2009-08-13 |
| AU2003223153A1 (en) | 2004-09-28 |
| US7581099B2 (en) | 2009-08-25 |
| US8850558B2 (en) | 2014-09-30 |
| US20070208950A1 (en) | 2007-09-06 |
| US20040177258A1 (en) | 2004-09-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8850558B2 (en) | Controlling access to a process using a separate hardware device | |
| JP6335280B2 (en) | User and device authentication in enterprise systems | |
| JP5795604B2 (en) | Method and apparatus for providing trusted single sign-on access to applications and Internet-based services | |
| US8683562B2 (en) | Secure authentication using one-time passwords | |
| TWI438642B (en) | Provisioning of digital identity representations | |
| EP2115654B1 (en) | Simplified management of authentication credentials for unattended applications | |
| US6973569B1 (en) | Inexpensive secure on-line certification authority system and method | |
| KR101451359B1 (en) | User account recovery | |
| US20040117662A1 (en) | System for indentity management and fortification of authentication | |
| CN114662079A (en) | Method and system for accessing data from multiple devices | |
| US20150121498A1 (en) | Remote keychain for mobile devices | |
| US9323911B1 (en) | Verifying requests to remove applications from a device | |
| US8051470B2 (en) | Consolidation of user directories | |
| WO2022144024A1 (en) | Attribute-based encryption keys as key material for key-hash message authentication code user authentication and authorization | |
| US10756899B2 (en) | Access to software applications | |
| KR101545897B1 (en) | A server access control system by periodic authentification of the smart card | |
| White et al. | Problems with DCE security services | |
| US20240056443A1 (en) | Secure cross-platform smart hosting, credential sharing, and identity management | |
| JP6334275B2 (en) | Authentication device, authentication method, authentication program, and authentication system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |
Effective date: 20130507 |
|
| FZDE | Discontinued |
Effective date: 20130507 |