WO2012038449A2 - Authentication - Google Patents
Authentication Download PDFInfo
- Publication number
- WO2012038449A2 WO2012038449A2 PCT/EP2011/066361 EP2011066361W WO2012038449A2 WO 2012038449 A2 WO2012038449 A2 WO 2012038449A2 EP 2011066361 W EP2011066361 W EP 2011066361W WO 2012038449 A2 WO2012038449 A2 WO 2012038449A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- server
- user
- key device
- information block
- key
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/80—Wireless
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
- H04W12/69—Identity-dependent
- H04W12/71—Hardware identity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
- H04W12/69—Identity-dependent
- H04W12/77—Graphical identity
Definitions
- the present invention concerns a key device and a system for authenticating a user, and methods for their use.
- Authenticating a person is the process of verifying that someone is who he or she claims to be. As used herein, authentication is a necessary, but not sufficient step, in granting someone access to an area where he or she is authorized to be.
- 'user' for a physical person, and provide examples mainly from an information system containing restricted information. However, the 'user' may be any person, and the restricted area may be a part of a building or any other restricted area.
- username and password are easily compromised, i.e. become known to unauthorized parties. Because it is difficult to remember an arbitrary string of numerals and letters, an email-address associated with the user is often used as the username. However, an email address is public, and each user typically has just a few of them. Hence, the username may be relatively easy to guess.
- 'password hints' used to be a common means to remember the password.
- a typical hint could be a question like 'what was your mother's maiden name', disregarding that such information might be relatively easy to obtain or guess.
- the confidentiality thereby becomes equal to the confidentiality of an open email.
- the email may become available to anyone with temporary access to the user's PC, for example if the password is stored by a 'remember me' functionality.
- passwords transmitted by and/or stored in an email system may relatively easy be intercepted or read by an unauthorized third party.
- usernames and passwords can be read by a spy program, which may be designed especially for logging sensitive information like password, username and credit card information.
- a spy program which may be designed especially for logging sensitive information like password, username and credit card information.
- anyone with access to a personal computer may access the email, find one or more passwords, and possibly access several sites per password.
- a second disadvantage of username and passwords is that they can be time consuming and inconvenient to enter on a cell phone or other handheld device. This is partly due to limited sizes of the keyboard and display, and partly due to other features of the user interface of handheld devices. For example, a mobile phone may have a numerical keyboard only, and require that one key is depressed several times in order to produce one character. Other devices may require accurately touching tiny keys on a small display by a thin and short handheld stylus. Hence, the average user spends an ever increasing amount of time entering usernames and passwords as the use of mobile devices becomes more widespread and frequent.
- a third disadvantage is that username and password is inherently inadequate to authenticate a user in an application with a stricter requirement for integrity.
- Network banking is an example of an application where it is desirable to ensure that the user really is who he or she claims to be before the user is allowed to perform a transaction, for example transfer money, and where a simple username/password authentication is considered inadequate.
- a typical authentication procedure in a networked banking application can require that the user first enters his or hers social security number, which is supposedly known to the user, and requires some effort to obtain. This identifies the user, and may also represent something the user knows. Next, a key generated by a code computer or a one-time key must be input. The key represents something the user has. In addition, a password representing something the user knows may be required.
- a second example of authentication is using a credit card and PIN in an ATM.
- An unauthorized third party may put a skimming device in front of the ATM.
- the skimmer retrieves information from a credit or debit card, and a small video camera monitor the keystrokes in order to obtain the PIN. Later, a copy of the card can be used with the PIN for withdrawals, purchases etc
- Username and password is an example of something the user knows only. Username/password is still employed in systems with less stringent requirements for authentication.
- An objective of the present invention is to provide an improved system and method addressing one or more of the problems described above.
- the server forwarding the message to an authentication server over a secure connection
- the server associating the user's private information with the open ID of the key device.
- the user can register her personal key device with a server at a service provider by photographing a graphical code displayed during a registration session on the server. Later, she can access her personal profile on the server simply by photographing another graphical code displayed in a public part of a site.
- the graphical code contains references to user validation methods required by the server, and which are to be enforced by the key device.
- the user validation methods are intended to ensure that an unauthorized user can use a key device to gain access to restricted areas available only to the owner of the key device.
- User validation methods may include recognizing facial features, fingerprints, iris, voice, password, PIN, signature etc.
- the encryption key is a one-time key.
- the invention regards a hand held key device for authenticating a user on a server, the key device comprising:
- a storage unit containing a hidden ID unique to the key device, and an encryption key, a control module capable of extracting an information block from the graphical code, and replacing at least a part of the information block with the hidden ID,
- an encryption module capable of encrypting the modified information block using the encryption key
- a communication module capable of transmitting the encrypted information block and other information over a communication network to and from the server.
- the hidden ID may be hardwired and tamperproof.
- the key device may optionally comprise a user validation module for authenticating a physical user on the key device, and for compliance with the biometric and non-biometric UVM- requirements of the server discussed above.
- the key device may optionally also store a list of one-time encryption keys.
- the invention concerns a system for authenticating a user on a server, the system comprising a key device as described above.
- the system comprises:
- a user terminal communicating with the server over a public network
- an authentication server communicating with the server over a secure connection
- the server (400) being adapted to associate the user's (200) private information with the open ID of the key device (100).
- the system may employ UVMs as discussed above, and identical lists of one-time encryption keys may be kept on the key-device and the authentication server.
- Fig. 1 is a schematic view of a key device
- Fig. 2 is a schematic view of a system for authentication.
- a user wants to register at a travel agent for simplifying future ticket ordering. She opens the travel agent's web pages, clicks on 'Register' and enters name, address, credit card number etc.
- This information is stored in a user profile, i.e. a restricted area. Conventionally, this information could be protected by a username and password, for example the user's email address and a generated password transmitted to the email-address as discussed above.
- the user instead uses a personal key device to photograph a graphical symbol presented on a display as part of the registration procedure. This associates a unique ID from the key device with the user's profile.
- the user wants to order a ticket. She enters the travel agent's web pages, and uses her key device to photograph another symbol displayed in a public part of the site. A moment later she is logged in, and ready to order her ticket.
- the personal key device in this example transmits
- the same key device can be used for several service providers, without the various providers having access to common information on the user. This means that even if one provider or site is compromised, the security of other sites is unaffected. In contrast, a usernames and password common to several sites would be compromised if the username and password was compromised on one of them.
- the key device can be used for controlling access to a physical area, e.g. a room in a building or a fenced in area, and for general transactions like paying at a shop, parking, or exchanging information.
- a lost key device might give an unauthorised person access to information or areas that should have been reserved for the owner of the key device. This can be avoided by requiring the user to verify her identity to the key device, and is discussed further below.
- FIG 1 is a schematic view of a key device 100 for authenticating a user on a server 400.
- the key device is typically a small handheld device and a separate physical entity. Because the key device does not necessarily need a keyboard or display, it can be made substantially smaller than a mobile phone, and can, for example, be attached to a key ring.
- the key device is a low power device powered by a small battery, for example implemented as an embedded device. Some strategies for saving power are left to the skilled person, for example keeping the component in a low power state and awaken them only when they are needed. These and other details known to the skilled person are only described to the extent they concern the invention. However, strategies for conserving power should be taken into account when designing a physical key device. It is also noted that the key device alternatively may be implemented on a mobile phone or PDA.
- the key device 100 comprises a camera 110 with sufficiently high resolution to separate the details in a graphical code can be separated from each other.
- a commercially available mobile camera can be utilized.
- a storage unit 120 contains a private hidden ID, hID, unique to the key device 100, an encryption key K and storage space for storing network references to a number of servers 400 and other information.
- the hID may be hardwired and tamperproof, i.e. provided in a way that cannot be altered by software or mechanical replacement. This may be achieved, for example, by providing the hID in a special hardware circuit, and encapsulating the circuit in epoxy resin. If someone attempted to remove or replace the circuit, it would break mechanically together with its connections. It is noted that no hash function is run on the key device in this embodiment. Rather, the hID is transmitted as is. This is done to save power, and will become clear from the description of the authentication server 500 below.
- the key device comprises a control module 130.
- the control module 130 is responsible for recognizing, analysing and manipulating graphically encoded information, and for controlling the other modules in the device. It can be implemented in several different ways known to the skilled person, for example as software in a general processor (CPU), optionally using a separate graphical processing unit (GPU). In order to save power, the CPU can, for example, be a low power state machine implemented in a field programmable array, and running an OS for embedded devices.
- An encryption module 140 is capable of encrypting the modified information block using an encryption key retrieved from the storage unit 120. If low power consumption is an aim, the key and a light weight encryption algorithm might be chosen to provide just the confidentiality required by the application at hand, rather than spending computing power on more secure encryption.
- a communication module 150 is capable of transmitting the encrypted information block and other information to and from a server 400.
- the communication module accesses a wireless network, e.g. WiFi, GSM or GPRS. Routers and other components required to transfer data to the server 400 is outside the scope of the present invention, and are thus not discussed further. It is noted that signals transmitted over a wireless network can be intercepted in most practical applications, which is why encryption is mandatory.
- the encryption key (K) has the exact same length as the data it encrypts. This way, there is no repetition due to the key, which may reduce the requirement for the encryption algorithm. As a light weight encryption algorithm is expected to consume less power than an algorithm requiring more computer resources, this may help conserving battery power.
- the key (K) can be a one-time key selected from a list stored in the storage module 120.
- An identical list can be stored in the authentication server 500 below, so that only a 'key number' referring to the list needs to be passed over to the authentication server 500.
- the information transmitted by the key device is different in every instance. Even two logins, one shortly after the other, to the same server would produce two distinct messages. This means that even if a message should be intercepted and analyzed, the information cannot be used to gain access to a restricted area at a later time, thereby making it difficult for unauthorized users to gain access to the restricted area.
- Fig. 1 An energy source, power saving functions, etc. are omitted from Fig. 1 for clarity. However, it is assumed obvious to the skilled person that such devices and functions are required to make a physical key device work.
- the modules disclosed above may also be arranged differently in any manner known to the skilled person.
- An optional user validation module 160 is responsible for ensuring that the physical user is a valid user of the personal key device.
- the user validation module has a set of capabilities, i.e. biometric 210 and/or non-biometric 211 user validation methods (UVMs) for verifying a physical person's identity on request from the server 400 (Fig. 2).
- biometric UVMs include, but are not limited to, scanning of facial features, scanning of fingerprints, iris-recognition and voice recognition.
- non-biometric UVMs include, but are not limited to, entering a personal identification number (PIN), entering a password, and recognizing a signature.
- PIN personal identification number
- Biometric and non-biometric UVMs can be used in any combination, only limited by the capabilities of the key device.
- the server 400 can require a certain combination of UVMs from the set of available capabilities, or, alternatively, disregard any key device not capable of providing the required .UVM(s).
- the user validation module 160 is responsible for enforcing the requirement. If, for example, the server 400 requires a fingerprint less than a minute ago, this is what the module 160 enforces. If the server 400 requires a PIN or a password alone or in combination with a fingerprint, this is what is required from the user 200 and enforced by the user validation module 160.
- the set of UVMs may be extended with the capabilities of new key devices.
- a code wheel 170 illustrates a possible interface for a non-biometric UVM, in which entering a 4-digit PIN is required.
- the code wheel 170 represents any possible alternative to keyboard and display for entering the required PIN or other data. It is left to the skilled person to decide which UVM(s) 210, 211 is/are required and/or desired for verifying the user 200 on the key device 100, and to provide appropriate means for the required UVM.
- one set of UVMs can be required by one network server and another set of UVMs can be required by a second network server.
- a third network server may require no UVM at all.
- Figure 2 shows a system for authenticating a user 200 on a server 400.
- the system and the key device 100 are mutually depending on each other.
- the user 200 also has access to a user terminal 300, e.g. a mobile phone, PDA or PC.
- the user terminal 300 is typically a client in a network based client/server-application.
- the client communicates with the server over a non-restricted, open network.
- a typical example of such a client/server- application is communication between a user terminal 300 (client) and a server 400 at a web shop or service provider by means of HTTP over Internet (public TCP/IP).
- the user terminal 300 may be mounted on a wall or fence, and server 400 can be a server controlling access to a restricted physical area. Still, at least the wireless signals sent to and from the key device can be intercepted.
- a session identifier Si is used to store and identify a a session between the server 400 and the user terminal 300.
- the detailed content of a session identifier depends on the communication protocol used and other factors. This is beyond the scope of the present invention.
- the user terminal 300 has a display 310 capable of displaying a graphic code.
- the graphic code represents a small information block I, e.g. 180-500b.
- the information block I preferentially has a payload part for e.g. a network address and/or instructions, and a randomly generated part.
- Means for transforming the information block I to a graphical symbol can be provided in the user terminal 300 or in the network server 400.
- Means for transforming the graphical symbol or code back to the information block I are provided in the key device 100.
- An authentication server 500 also known as master server (MS), contains a public reference to each key device 100, and a value resulting from a validation function performed on the unique hidden key 121 of each key device 100. Further, the authentication server 500 comprises means for decrypting messages from the key device 100.
- MS master server
- the authentication server 500 is a service available to all servers 400. In principle, this service could run on the server 400. However, this could limit the functionality if all key devices 100 and servers 400 would have to use a common encryption key and encryption algorithm. Alternatively, server 400 might contain all keys for all key devices. As the server 400 is connected to a public network, the latter solution could impose an increased risk for losing confidentiality. The increased risk translates to increased cost for protection. If the cost is acceptable, e.g. to ensure availability, it would be possible to run the authentication service on, for example, a server 400 connected to an open network. On the other hand, a dedicated authentication server 500 may accept messages from a set of predefined servers 400 only, and reject messages from anyone else.
- a valid connection may require that both parties identify themselves using certificates, and that messages over the connection is provided with a cryptographic check sum (a hash) to prevent unauthorized alterations in transit.
- the messages may also be encrypted/decrypted at each end of the connection to ensure confidentiality.
- a 'tunnel' as used herein is a two way channel with integrity and confidentiality control in both directions as described above.
- the integrity and confidentiality levels of the tunnel must be adapted to the application, e.g. balanced against the computer resources needed for hashing and encryption with a given traffic.
- the servers 400 are connected to dedicated authentication servers 500 through secure connections, for example the tunnels described above, or a well protected connection within one physical machine between the servers 400 and 500.
- the authentication server 500 may be further protected against other known threats by known means, for example by ensuring that every response is returned on the exact channel on which the incoming message was received, denying access after several unsuccessful attempts or requests, etc.
- the authentication service should be available for all servers 400 in the system, and unavailable for everyone else.
- Server 400 generates an information block I comprising, among other data, references to the user validation method(s) (UVMs) discussed above that is/are required by this particular server 400, and a predetermined reference to server 400.
- Server 400 stores I, or a sufficiently large part of I to be unique on server 400, and associates I with the information the user is entering or has entered.
- Server 400 then transmits the information block I to user terminal 300.
- the information block I is transformed to graphical code, which is displayed on the display 310, e.g. as a graphical symbol on a page associated with the registration procedure.
- the information block I contains a reference to server 400, such that the key device can return a response to the correct location.
- the information block may optionally contain one or more references to user validation methods (UVMs) required by the server 400.
- the key device 100 stores any reference to a UVM with the reference to server 400 in the storage unit 120, replaces the part of the information block that contained the reference to UVMs and to the server 400 with the hidden unique ID, hID, and encrypts the new I-block.
- An open unique ID, oID is enclosed with the encrypted message in a message M.
- the message M containing the encrypted message and the oID, is transmitted to the server 400 through the communication module 150, for example via WiFi, wireless GSM or some other wireless network available in the vicinity of the key device.
- Server 400 forwards M unaltered to the authentication server 500.
- Authentication server 500 uses the oID to lookup the encryption key and/or decryption function, in addition to a stored hash of the hID of the present key device 100, hash(hID) AUT . Authentication server 500 then decrypts the encrypted message within M, retrieves the hID of the key device 100 from the decrypted message, and creates a hash value hash(hID) KEY .
- hash(hID) AUT stored on the authentication server is identical to hash(hID) KEY derived from the received message, I is returned to server 400 along with oID (not hID).
- server 400 always forwards the message M to the
- the process halts and access is denied. This is because the open ID oID and the information block I are regarded as open and available information, and are considered reliable only if they have been through an encryption/decryption process.
- Server 400 receives I, looks up I in its own database and finds that I is associated with information belonging to user 200. Server 400 replaces I in the association with oID. The oID of the key device is now associated with all information belonging to user 200 in the customer registry on server 400.
- Server 400 has a session S 1 with a user, unknown to the server, which user requests access. Server 400 does still not know that the unknown user is user 200.
- Server 400 generates an information block I, stores I or a sufficiently large part of I to be unique on the server, and associates I with the session S I. I is then transformed and displayed on the display 310 of a user terminal as a graphical code as described above.
- User 200 reads the graphical code with her personal key device 100.
- a message M is generated on the key device, and sent to the authentication server 500 via server 400 in the same manner as above.
- the authentication server 500 decrypts M and computes a hash value from the hID therein. Again, the derived value is compared to a value stored in the authentication server 500. If the two hashes are identical, I is returned to server 400 together with oID (not hID). Now, server 400 performs two different searches:
- server 400 looks up oID in its own registry and finds information
- server 400 looks up I (or the stored part of I), and finds a session reference, here S I.
- Server 400 now associates the found session S I, still belonging to an unknown user, with user 200. Server 400 then redirects the formerly unknown user of S 1 to the restricted area of the newly identified user 200.
- the key device 100 may send all messages M to a fixed 'default server'.
- the default server may contain username/oID
- the mode of operation remains substantially as above.
- the default server communicates with both the authentication server 500 and the network site and works like a dispatcher.
- the default server can contain several registers for different network sites.
Abstract
A user (200) is provided with a handheld key device (100). A user terminal (300) associated with the user communicates with a network server (400) at a service provider over a public network. The key device (100) is associated with the user (200) in a registration session on the network server (400) by photographing a graphically encoded symbol displayed on the user terminal (300) with the key device (100), returning an encrypted message containing information retrieved from the symbol and IDs identifying the key device (100) over the public network, and using session information to associate the key device (100) with the user's profile. In a later session, the user can use the key device (100) to photograph another graphical code displayed on a public part of the site to access her user profile. The physical user (200) is preferably authenticated on the key device (100) using biometric (210) and/or non-biometric (211) identification. The requirements for authenticating the user on the key device can depend on the application, and may be communicated from the network server (400) to the key device (100) through the graphical code or symbol.
Description
Title
Authentication
BACKGROUND
Field of the invention
The present invention concerns a key device and a system for authenticating a user, and methods for their use.
Prior and related art
Authenticating a person is the process of verifying that someone is who he or she claims to be. As used herein, authentication is a necessary, but not sufficient step, in granting someone access to an area where he or she is authorized to be. Hereafter we use the term 'user' for a physical person, and provide examples mainly from an information system containing restricted information. However, the 'user' may be any person, and the restricted area may be a part of a building or any other restricted area.
Today, associating a user to a username and requiring the user to enter a password known only to him or her, is a widely used method for authenticating the user and granting access to, for example, applications, personal profiles or information for which the user is authorized, and to deny unauthorized users access to such information.
A first disadvantage of username and password is that they are easily compromised, i.e. become known to unauthorized parties. Because it is difficult to remember an arbitrary string of numerals and letters, an email-address associated with the user is often used as the username. However, an email address is public, and each user typically has just a few of them. Hence, the username may be relatively easy to guess.
Regarding passwords, 'password hints' used to be a common means to remember the password. A typical hint could be a question like 'what was your mother's maiden name', disregarding that such information might be relatively easy to obtain or guess. At present, it is more common to generate a new password which is transmitted to the user in an open email. However, the confidentiality thereby becomes equal to the confidentiality of an open email. The email may become available to anyone with temporary access to the user's PC, for example if the password is stored by a 'remember me' functionality. In general, passwords
transmitted by and/or stored in an email system may relatively easy be intercepted or read by an unauthorized third party.
Further, usernames and passwords can be read by a spy program, which may be designed especially for logging sensitive information like password, username and credit card information. As the number of profiles containing personal information increases, it becomes increasingly difficult to remember different passwords, especially if several passwords are arbitrary strings of numerals and letters. Hence, users tend to use one username/password-combination in several contexts. This means that one compromised username/password may compromise several protected sites.
In short, anyone with access to a personal computer may access the email, find one or more passwords, and possibly access several sites per password.
A second disadvantage of username and passwords is that they can be time consuming and inconvenient to enter on a cell phone or other handheld device. This is partly due to limited sizes of the keyboard and display, and partly due to other features of the user interface of handheld devices. For example, a mobile phone may have a numerical keyboard only, and require that one key is depressed several times in order to produce one character. Other devices may require accurately touching tiny keys on a small display by a thin and short handheld stylus. Hence, the average user spends an ever increasing amount of time entering usernames and passwords as the use of mobile devices becomes more widespread and frequent.
A third disadvantage is that username and password is inherently inadequate to authenticate a user in an application with a stricter requirement for integrity. Network banking is an example of an application where it is desirable to ensure that the user really is who he or she claims to be before the user is allowed to perform a transaction, for example transfer money, and where a simple username/password authentication is considered inadequate. A typical authentication procedure in a networked banking application can require that the user first enters his or hers social security number, which is supposedly known to the user, and requires some effort to obtain. This identifies the user, and may also represent something the user knows. Next, a key generated by a code computer or a one-time key must be input. The key represents something the user has. In addition, a password representing something the user knows may be required.
A second example of authentication is using a credit card and PIN in an ATM. An unauthorized third party may put a skimming device in front of the ATM. The skimmer retrieves information from a credit or debit card, and a small video camera monitor the keystrokes in order to obtain the PIN. Later, a copy of the card can be used with the PIN for withdrawals, purchases etc
In general, it is common practice to require something the user has and something the user knows in order to authenticate the user in an information system with strict conditions for granting access to restricted information. Username and password is an example of something the user knows only. Username/password is still employed in systems with less stringent requirements for authentication.
Similarly, requiring only something that the user has is known from, for example, applications where it is sufficient to swipe a credit card to authenticate a user. Such applications typically debit a limited amount of money, e.g. buying a ticket for an airport express train or paying for a parking slot.
Due to the inconvenience of entering long strings of characters on a hand held terminal, graphical codes have been developed. The codes can be read and deciphered by an ordinary camera found in handheld devices. Today, such a code would typically be printed in an advertisement, so that the interested user may photograph the code and automatically be directed to a public webpage with more information without having to enter a long web-address through a keyboard.
However, this technique cannot be employed without modification for authenticating a user: Anyone photographing the graphically coded symbol gets access to the public web page.
An objective of the present invention is to provide an improved system and method addressing one or more of the problems described above.
SUMMARY OF THE INVENTION
This can be achieved by providing a method for authenticating a user on a server, the method comprising the steps of:
providing the user with a personal key device and a user terminal communicating with the server over a public network,
providing an authentication server communicating with the server over a secure connection,
generating an information block containing a reference to the server and a random part,
presenting the information block as a graphical code on a display connected to the user terminal,
photographing the graphical code with the key device,
the key device
transforming the graphical code to the information block;
retrieving a reference to the server from the information block, storing the reference in the key device,
replacing part of the information block with a hidden unique ID, encrypting the modified information block,
enclosing an open ID with the encrypted block in a message, and transmitting the message to the server;
the server forwarding the message to an authentication server over a secure connection,
the authentication server
retrieving an encryption key, an encryption algorithm and a first hash of a hidden ID from a registry using the open ID;
decrypting the encrypted modified information block; computing a second hash of the key device's hidden ID retrieved from the modified information block;
comparing the first and second hashes of hidden IDs, and
returning, over the secure connection, the unencrypted modified information block and open ID to the server from which the message was received;
the server associating the user's private information with the open ID of the key device.
Using this method, the user can register her personal key device with a server at a service provider by photographing a graphical code displayed during a registration session on the server. Later, she can access her personal profile on the server simply by photographing another graphical code displayed in a public part of a site.
In a preferred embodiment, the graphical code contains references to user validation methods required by the server, and which are to be enforced by the key device. The user validation methods are intended to ensure that an unauthorized user can use a key device to gain access to restricted areas available only to the owner of the key device. User validation methods may include recognizing facial features, fingerprints, iris, voice, password, PIN, signature etc.
Advantageously, the encryption key is a one-time key.
In another aspect, the invention regards a hand held key device for authenticating a user on a server, the key device comprising:
a camera capable of resolving elements in a graphical code,
a storage unit containing a hidden ID unique to the key device, and an encryption key,
a control module capable of extracting an information block from the graphical code, and replacing at least a part of the information block with the hidden ID,
an encryption module capable of encrypting the modified information block using the encryption key; and
a communication module capable of transmitting the encrypted information block and other information over a communication network to and from the server.
The hidden ID may be hardwired and tamperproof. The key device may optionally comprise a user validation module for authenticating a physical user on the key device, and for compliance with the biometric and non-biometric UVM- requirements of the server discussed above. The key device may optionally also store a list of one-time encryption keys.
In yet another aspect, the invention concerns a system for authenticating a user on a server, the system comprising a key device as described above. In addition, the system comprises:
a user terminal communicating with the server over a public network, an authentication server communicating with the server over a secure connection,
means for generating an information block containing a reference to the server and a random part,
means for presenting the information block as a graphical code on a display connected to the user terminal,
means for receiving a message and forwarding it to an authentication server, the message comprising an encrypted modified information block and an open ID, the authentication server being adapted to
retrieve an encryption key, an encryption algorithm and a first hash of a hidden ID from a registry using the open ID;
decrypt the encrypted modified information block;
computing a second hash of the key device's hidden ID retrieved from the modified information block;
comparing the first and second hashes of hidden IDs, and
returning, over the secure connection; the unencrypted modified information block and open ID to the server from which the message was received,
the server (400) being adapted to associate the user's (200) private information with the open ID of the key device (100).
The system may employ UVMs as discussed above, and identical lists of one-time encryption keys may be kept on the key-device and the authentication server.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention is explained in the following detailed description with reference to the appended drawings, in which:
Fig. 1 is a schematic view of a key device, and
Fig. 2 is a schematic view of a system for authentication.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
Assume that a user wants to register at a travel agent for simplifying future ticket ordering. She opens the travel agent's web pages, clicks on 'Register' and enters name, address, credit card number etc. This information is stored in a user profile, i.e. a restricted area. Conventionally, this information could be protected by a username and password, for example the user's email address and a generated password transmitted to the email-address as discussed above. According to the present invention, the user instead uses a personal key device to photograph a graphical symbol presented on a display as part of the registration procedure. This associates a unique ID from the key device with the user's profile.
Some time later, the user wants to order a ticket. She enters the travel agent's web pages, and uses her key device to photograph another symbol displayed in a public part of the site. A moment later she is logged in, and ready to order her ticket.
In other words, the personal key device in this example transmits
authentication information to a server at the travel agent. The same key device can be used for several service providers, without the various providers having access to common information on the user. This means that even if one provider or site is compromised, the security of other sites is unaffected. In contrast, a usernames and password common to several sites would be compromised if the username and password was compromised on one of them.
In a manner similar to the one in the example above, the key device can be used for controlling access to a physical area, e.g. a room in a building or a fenced in area, and for general transactions like paying at a shop, parking, or exchanging information.
As with any key, a lost key device might give an unauthorised person access to information or areas that should have been reserved for the owner of the key device. This can be avoided by requiring the user to verify her identity to the key device, and is discussed further below.
Referring now to the appended drawings, it is noted that they are schematic views, that numerous details are omitted for clarity, and that they are not to scale.
Figure 1 is a schematic view of a key device 100 for authenticating a user on a server 400. The key device is typically a small handheld device and a separate physical entity. Because the key device does not necessarily need a keyboard or display, it can be made substantially smaller than a mobile phone, and can, for example, be attached to a key ring. In a preferred embodiment, the key device is a low power device powered by a small battery, for example implemented as an embedded device. Some strategies for saving power are left to the skilled person, for example keeping the component in a low power state and awaken them only when they are needed. These and other details known to the skilled person are only described to the extent they concern the invention. However, strategies for conserving power should be taken into account when designing a physical key device. It is also noted that the key device alternatively may be implemented on a mobile phone or PDA.
The key device 100 comprises a camera 110 with sufficiently high resolution to separate the details in a graphical code can be separated from each other. A commercially available mobile camera can be utilized.
A storage unit 120 contains a private hidden ID, hID, unique to the key device 100, an encryption key K and storage space for storing network references to a number of servers 400 and other information. Using commercially available flash memory, a storage space of a few GB is readily available even in a low power, low cost device. The hID may be hardwired and tamperproof, i.e. provided in a way that cannot be altered by software or mechanical replacement. This may be achieved, for example, by providing the hID in a special hardware circuit, and encapsulating the circuit in epoxy resin. If someone attempted to remove or replace the circuit, it would break mechanically together with its connections. It is noted that no hash function is run on the key device in this embodiment. Rather, the hID is transmitted as is. This is done to save power, and will become clear from the description of the authentication server 500 below.
Further, the key device comprises a control module 130. The control module 130 is responsible for recognizing, analysing and manipulating graphically encoded information, and for controlling the other modules in the device. It can be
implemented in several different ways known to the skilled person, for example as software in a general processor (CPU), optionally using a separate graphical processing unit (GPU). In order to save power, the CPU can, for example, be a low power state machine implemented in a field programmable array, and running an OS for embedded devices.
An encryption module 140 is capable of encrypting the modified information block using an encryption key retrieved from the storage unit 120. If low power consumption is an aim, the key and a light weight encryption algorithm might be chosen to provide just the confidentiality required by the application at hand, rather than spending computing power on more secure encryption.
A communication module 150 is capable of transmitting the encrypted information block and other information to and from a server 400. For practical reasons, the communication module accesses a wireless network, e.g. WiFi, GSM or GPRS. Routers and other components required to transfer data to the server 400 is outside the scope of the present invention, and are thus not discussed further. It is noted that signals transmitted over a wireless network can be intercepted in most practical applications, which is why encryption is mandatory.
In a preferred embodiment, the encryption key (K) has the exact same length as the data it encrypts. This way, there is no repetition due to the key, which may reduce the requirement for the encryption algorithm. As a light weight encryption algorithm is expected to consume less power than an algorithm requiring more computer resources, this may help conserving battery power.
.Further, the key (K) can be a one-time key selected from a list stored in the storage module 120. An identical list can be stored in the authentication server 500 below, so that only a 'key number' referring to the list needs to be passed over to the authentication server 500. In this embodiment, the information transmitted by the key device is different in every instance. Even two logins, one shortly after the other, to the same server would produce two distinct messages. This means that even if a message should be intercepted and analyzed, the information cannot be used to gain access to a restricted area at a later time, thereby making it difficult for unauthorized users to gain access to the restricted area.
An energy source, power saving functions, etc. are omitted from Fig. 1 for clarity. However, it is assumed obvious to the skilled person that such devices and functions are required to make a physical key device work. The modules disclosed above may also be arranged differently in any manner known to the skilled person.
An optional user validation module 160 is responsible for ensuring that the physical user is a valid user of the personal key device. The user validation module has a set of capabilities, i.e. biometric 210 and/or non-biometric 211 user validation
methods (UVMs) for verifying a physical person's identity on request from the server 400 (Fig. 2). Examples of biometric UVMs include, but are not limited to, scanning of facial features, scanning of fingerprints, iris-recognition and voice recognition. Examples of non-biometric UVMs include, but are not limited to, entering a personal identification number (PIN), entering a password, and recognizing a signature. Biometric and non-biometric UVMs can be used in any combination, only limited by the capabilities of the key device. In a preferred embodiment, the server 400 can require a certain combination of UVMs from the set of available capabilities, or, alternatively, disregard any key device not capable of providing the required .UVM(s). The user validation module 160 is responsible for enforcing the requirement. If, for example, the server 400 requires a fingerprint less than a minute ago, this is what the module 160 enforces. If the server 400 requires a PIN or a password alone or in combination with a fingerprint, this is what is required from the user 200 and enforced by the user validation module 160. The set of UVMs may be extended with the capabilities of new key devices.
A code wheel 170 illustrates a possible interface for a non-biometric UVM, in which entering a 4-digit PIN is required. The code wheel 170 represents any possible alternative to keyboard and display for entering the required PIN or other data. It is left to the skilled person to decide which UVM(s) 210, 211 is/are required and/or desired for verifying the user 200 on the key device 100, and to provide appropriate means for the required UVM.
In general, one set of UVMs can be required by one network server and another set of UVMs can be required by a second network server. A third network server may require no UVM at all.
Figure 2 shows a system for authenticating a user 200 on a server 400. The system and the key device 100 are mutually depending on each other.
The user 200 also has access to a user terminal 300, e.g. a mobile phone, PDA or PC. The user terminal 300 is typically a client in a network based client/server-application. In principle, the client communicates with the server over a non-restricted, open network. A typical example of such a client/server- application is communication between a user terminal 300 (client) and a server 400 at a web shop or service provider by means of HTTP over Internet (public TCP/IP). In another application, the user terminal 300 may be mounted on a wall or fence, and server 400 can be a server controlling access to a restricted physical area. Still, at least the wireless signals sent to and from the key device can be intercepted.
A session identifier Si is used to store and identify a a session between the server 400 and the user terminal 300. The detailed content of a session identifier
depends on the communication protocol used and other factors. This is beyond the scope of the present invention.
The user terminal 300 has a display 310 capable of displaying a graphic code. The graphic code represents a small information block I, e.g. 180-500b. The information block I preferentially has a payload part for e.g. a network address and/or instructions, and a randomly generated part. Means for transforming the information block I to a graphical symbol can be provided in the user terminal 300 or in the network server 400. Means for transforming the graphical symbol or code back to the information block I are provided in the key device 100.
An authentication server 500, also known as master server (MS), contains a public reference to each key device 100, and a value resulting from a validation function performed on the unique hidden key 121 of each key device 100. Further, the authentication server 500 comprises means for decrypting messages from the key device 100.
The authentication server 500 is a service available to all servers 400. In principle, this service could run on the server 400. However, this could limit the functionality if all key devices 100 and servers 400 would have to use a common encryption key and encryption algorithm. Alternatively, server 400 might contain all keys for all key devices. As the server 400 is connected to a public network, the latter solution could impose an increased risk for losing confidentiality. The increased risk translates to increased cost for protection. If the cost is acceptable, e.g. to ensure availability, it would be possible to run the authentication service on, for example, a server 400 connected to an open network. On the other hand, a dedicated authentication server 500 may accept messages from a set of predefined servers 400 only, and reject messages from anyone else. Rather than just accepting an IP-address as proof of identity, a valid connection may require that both parties identify themselves using certificates, and that messages over the connection is provided with a cryptographic check sum (a hash) to prevent unauthorized alterations in transit. The messages may also be encrypted/decrypted at each end of the connection to ensure confidentiality. A 'tunnel' as used herein is a two way channel with integrity and confidentiality control in both directions as described above. The integrity and confidentiality levels of the tunnel must be adapted to the application, e.g. balanced against the computer resources needed for hashing and encryption with a given traffic. In general, the servers 400 are connected to dedicated authentication servers 500 through secure connections, for example the tunnels described above, or a well protected connection within one physical machine between the servers 400 and 500. The authentication server 500 may be further protected against other known threats by known means, for example by
ensuring that every response is returned on the exact channel on which the incoming message was received, denying access after several unsuccessful attempts or requests, etc. In all implementations, the authentication service should be available for all servers 400 in the system, and unavailable for everyone else.
In principle, it would be possible to provide tunnels all the way from key device 100 to authentication server 500. However, this would require the key device to hash all incoming and outgoing messages and to decrypt all incoming messages in addition to the only really required encryption of outgoing messages. As the computation requires battery power, the present solution is preferred in a low power key device, e.g. in order to prolong battery life.
The system's mode of operation will be disclosed in greater detail in the following, still with reference to Fig. 2. Further, assume that the user 200 is identified or a new user profile is being created, for example in that the user is entering personal data on server 400 at a service provider as in the example above.
Server 400 generates an information block I comprising, among other data, references to the user validation method(s) (UVMs) discussed above that is/are required by this particular server 400, and a predetermined reference to server 400. Server 400 stores I, or a sufficiently large part of I to be unique on server 400, and associates I with the information the user is entering or has entered. Server 400 then transmits the information block I to user terminal 300. In transit, i.e. in the server 400, in the user terminal 300, or in a web browser on the user terminal 300, the information block I is transformed to graphical code, which is displayed on the display 310, e.g. as a graphical symbol on a page associated with the registration procedure.
User 200 photographs the displayed graphical symbol with her personal key device, which thereafter decodes the symbol and retrieves the information block I.
The information block I contains a reference to server 400, such that the key device can return a response to the correct location. The information block may optionally contain one or more references to user validation methods (UVMs) required by the server 400. The key device 100 stores any reference to a UVM with the reference to server 400 in the storage unit 120, replaces the part of the information block that contained the reference to UVMs and to the server 400 with the hidden unique ID, hID, and encrypts the new I-block. An open unique ID, oID, is enclosed with the encrypted message in a message M. The message M, containing the encrypted message and the oID, is transmitted to the server 400 through the communication module 150, for example via WiFi, wireless GSM or
some other wireless network available in the vicinity of the key device. Server 400 forwards M unaltered to the authentication server 500.
Authentication server 500 uses the oID to lookup the encryption key and/or decryption function, in addition to a stored hash of the hID of the present key device 100, hash(hID)AUT. Authentication server 500 then decrypts the encrypted message within M, retrieves the hID of the key device 100 from the decrypted message, and creates a hash value hash(hID)KEY.
If the hash(hID)AUT stored on the authentication server is identical to hash(hID)KEY derived from the received message, I is returned to server 400 along with oID (not hID).
It is possible to store and compare hID directly. However, comparing functional values of the hIDs is preferred to avoid storing the hIDs in clear. Any function which computes a value from a hID fast, and which makes it difficult or impossible to derive the hID from the functional value, is suitable. Examples of known such functions include the hash functions MD5, SHA-1, SHA-2 and
RIPEMD-160.
It is noted that server 400 always forwards the message M to the
authentication server 500. If the message is not encrypted, decryption at the authentication server causes an error when testing the hidden ID, the process halts and access is denied. This is because the open ID oID and the information block I are regarded as open and available information, and are considered reliable only if they have been through an encryption/decryption process.
Server 400 receives I, looks up I in its own database and finds that I is associated with information belonging to user 200. Server 400 replaces I in the association with oID. The oID of the key device is now associated with all information belonging to user 200 in the customer registry on server 400.
Next, assume that user 200 wants to log in on server 400 at a later point in time. Server 400 has a session S 1 with a user, unknown to the server, which user requests access. Server 400 does still not know that the unknown user is user 200.
Server 400 generates an information block I, stores I or a sufficiently large part of I to be unique on the server, and associates I with the session S I. I is then transformed and displayed on the display 310 of a user terminal as a graphical code as described above.
User 200 reads the graphical code with her personal key device 100. A message M is generated on the key device, and sent to the authentication server 500 via server 400 in the same manner as above. The authentication server 500 decrypts M and computes a hash value from the hID therein. Again, the derived value is
compared to a value stored in the authentication server 500. If the two hashes are identical, I is returned to server 400 together with oID (not hID). Now, server 400 performs two different searches:
1) server 400 looks up oID in its own registry and finds information
associated with user 200, and
2) server 400 then looks up I (or the stored part of I), and finds a session reference, here S I.
Server 400 now associates the found session S I, still belonging to an unknown user, with user 200. Server 400 then redirects the formerly unknown user of S 1 to the restricted area of the newly identified user 200.
In an alternative embodiment, the key device 100 may send all messages M to a fixed 'default server'. The default server may contain username/oID
associations on behalf of network sites that do not wish to have their own receiving server 400. The mode of operation remains substantially as above. However, the default server communicates with both the authentication server 500 and the network site and works like a dispatcher. The default server can contain several registers for different network sites.
Claims
1. Method for authenticating a user (200) on a server (400), the method comprising the steps of:
providing the user (200) with a personal key device (100) and a user terminal (300) communicating with the server (400) over a public network,
providing an authentication server (500) communicating with the server (400) over a secure connection,
generating an information block containing a reference to the server (400) and a random part,
presenting the information block as a graphical code on a display (310) connected to the user terminal (300),
photographing the graphical code with the key device (100),
the key device
transforming the graphical code to the information block;
retrieving a reference to the server (400) from the information block, storing the reference in the key device,
replacing part of the information block with a hidden unique ID, encrypting the modified information block,
enclosing an open ID with the encrypted block in a message, and transmitting the message to the server 400;
the server 400 forwarding the message to an authentication server (500) over a secure connection,
the authentication server (500)
retrieving an encryption key (K), an encryption algorithm and a first hash of a hidden ID from a registry using the open ID; decrypting the encrypted modified information block; computing a second hash of the key device's hidden ID retrieved from the modified information block;
comparing the first and second hashes of hidden IDs, and
returning, over the secure connection, the unencrypted modified information block and open ID to the server (400) from which the message (M) was received over the secure connection; the server (400) associating the user's (200) private information with the open ID of the key device (100).
2. Method according to claim 1, wherein the information block contains at least one reference to a user validation method required by the server 400.
3. Method according to claim 2, wherein the user validation method is selected from a group comprising facial recognition, fingerprint recognition, iris recognition, voice recognition, password recognition, PIN recognition and signature recognition.
4. Method according to any preceding claim, wherein the encryption key is a one-time key.
5. A hand held key device (100) for authenticating a user (200) on a server (400), the key device (100) comprising
a camera (110) capable of resolving elements in a graphical code,
a storage unit (120) containing a hidden ID (hID) unique to the key device
(100), and an encryption key (K),
a control module (130) capable of extracting an information block from the graphical code, and replacing at least a part of the information block with the hidden
ID (hID),
an encryption module (140) capable of encrypting the modified information block using the encryption key (K); and
a communication module (150) capable of transmitting the encrypted information block and other information over a communication network to and from the server (400).
6. Key device according to claim 5, further comprising a user validation module (160) for authenticating a physical user (200) on the key device (100).
7. Key device according to claim 6, wherein the user validation module (160) comprises biometric user validation means for authenticating the user (200) by a characteristic selected from a group comprising facial features, fingerprint, iris pattern, and voice.
8. Key device according to claim 6 or 7, wherein the user validation module (160) comprises non-biometric user validation means for authenticating the user (200) by requiring the user to input information selected from a group comprising a password, a personal identification number, and a signature.
9. Key device according to any claim 6 through 8, wherein the key device (100) is adapted to receive, from the server (400), a requirement for using specific user validation means; for storing the requirement in the storage unit (120); and for preventing transmission to the server (400) if the requirement for user validation is not complied with.
10. Key device according to any claim 6 through 9, wherein the hidden ID is hardwired and tamperproof.
11. Key device according to any claim 6 through 10, wherein the encryption key (K) is a one-time key.
12. A system for authenticating a user (200) on a server (400), the system comprising a key device (100) according to any claim 6 through 11, and in addition: a user terminal (300) communicating with the server (400) over a public network,
an authentication server (500) communicating with the server (400) over a secure connection,
means for generating an information block containing a reference to the server (400) and a random part,
means for presenting the information block as a graphical code on a display (310) connected to the user terminal (300),
means for receiving a message (M) and forwarding it to an authentication server (500), the message (M) comprising an encrypted modified information block and an open ID,
the authentication server (500) being adapted to
retrieve an encryption key (K), an encryption algorithm and a first hash of a hidden ID from a registry using the open ID; decrypt the encrypted modified information block;
computing a second hash of the key device's hidden ID retrieved from the modified information block;
comparing the first and second hashes of hidden IDs, and
returning, over the secure connection, the unencrypted modified information block and open ID to the server (400) from which the message (M) was received;
the server (400) being adapted to associate the user's (200) private
information with the open ID of the key device (100).
13. System according to claim 12, wherein the information block and graphical symbol contains a reference to at least one user validation method which is required to be enforced by the key device (100).
14. System according to claim 13, wherein the user validation method is selected from a group comprising facial recognition, fingerprint recognition, iris recognition, voice recognition, password recognition, PIN recognition and signature recognition.
15. System according to any claim 12 through 14, wherein the encryption key (K) is a one-time key, and the key device (100) and authentication server (500) stores identical lists of encryption keys, whereby transmitting the key's number in the list is sufficient to identify the key for decryption.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP11758473.0A EP2619940A2 (en) | 2010-09-20 | 2011-09-20 | Authentication |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
NO20101310 | 2010-09-20 | ||
NO20101310 | 2010-09-20 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2012038449A2 true WO2012038449A2 (en) | 2012-03-29 |
WO2012038449A3 WO2012038449A3 (en) | 2012-05-18 |
Family
ID=44658759
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2011/066361 WO2012038449A2 (en) | 2010-09-20 | 2011-09-20 | Authentication |
Country Status (2)
Country | Link |
---|---|
EP (1) | EP2619940A2 (en) |
WO (1) | WO2012038449A2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11213773B2 (en) | 2017-03-06 | 2022-01-04 | Cummins Filtration Ip, Inc. | Genuine filter recognition with filter monitoring system |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7021534B1 (en) * | 2004-11-08 | 2006-04-04 | Han Kiliccote | Method and apparatus for providing secure document distribution |
WO2010066304A1 (en) * | 2008-12-12 | 2010-06-17 | Nec Europe Ltd. | Universal mobile verifier |
-
2011
- 2011-09-20 EP EP11758473.0A patent/EP2619940A2/en not_active Withdrawn
- 2011-09-20 WO PCT/EP2011/066361 patent/WO2012038449A2/en active Application Filing
Non-Patent Citations (1)
Title |
---|
None |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11213773B2 (en) | 2017-03-06 | 2022-01-04 | Cummins Filtration Ip, Inc. | Genuine filter recognition with filter monitoring system |
Also Published As
Publication number | Publication date |
---|---|
EP2619940A2 (en) | 2013-07-31 |
WO2012038449A3 (en) | 2012-05-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11647023B2 (en) | Out-of-band authentication to access web-service with indication of physical access to client device | |
CN106464673B (en) | Enhanced security for authenticating device registration | |
US8485438B2 (en) | Mobile computing device authentication using scannable images | |
EP2937805B1 (en) | Proximity authentication system | |
US9628460B2 (en) | Method of controlling access to an internet-based application | |
US20090265769A1 (en) | Method for automatically generating and filling in login information and system for the same | |
KR20180117715A (en) | Method and system for user authentication with improved security | |
WO2015188426A1 (en) | Method, device, system, and related device for identity authentication | |
KR20110081103A (en) | Secure transaction systems and methods | |
KR20150093781A (en) | Barcode authentication for resource requests | |
KR20110130770A (en) | Iris information based 3-factor user authentication method for otp generation and secure two way authentication system of wireless communication device authentication using otp | |
US10972465B1 (en) | Secure authentication through visual codes containing unique metadata | |
CN116529729A (en) | Integrated circuit for obtaining enhanced rights to network-based resources and performing actions in accordance therewith | |
WO2012038449A2 (en) | Authentication | |
WO2016042473A1 (en) | Secure authentication using dynamic passcode | |
WO2016013924A1 (en) | System and method of mutual authentication using barcode | |
EP3570518B1 (en) | Authentication system and method using a limited-life disposable token | |
Matei-Dimitrie | Multi-factor authentication. An extended overview | |
US20180332028A1 (en) | Method For Detecting Unauthorized Copies Of Digital Security Tokens | |
JP2021093063A (en) | Information processing device, authentication system, information processing method, and authentication method | |
JP2004021591A (en) | Management device and authentication device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 11758473 Country of ref document: EP Kind code of ref document: A2 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2011758473 Country of ref document: EP |