WO2012038449A2 - Authentification - Google Patents

Authentification Download PDF

Info

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
Application number
PCT/EP2011/066361
Other languages
English (en)
Other versions
WO2012038449A3 (fr
Inventor
Steinbakk Karl Erik
Original Assignee
Perid As
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Perid As filed Critical Perid As
Priority to EP11758473.0A priority Critical patent/EP2619940A2/fr
Publication of WO2012038449A2 publication Critical patent/WO2012038449A2/fr
Publication of WO2012038449A3 publication Critical patent/WO2012038449A3/fr

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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)
  • User Interface Of Digital Computer (AREA)

Abstract

Un utilisateur (200) est muni d'un dispositif à touches portable (100). Un terminal d'utilisateur (300) associé à l'utilisateur communique par un réseau public avec un serveur de réseau (400) chez un fournisseur de services. Le dispositif à touches (100) est associé à l'utilisateur (200) lors d'une session d'enregistrement sur le serveur de réseau (400) par les étapes consistant à photographier au moyen du dispositif à touches (100) un symbole à codage graphique affiché sur le terminal d'utilisateur (300), à renvoyer sur le réseau public un message chiffré contenant des informations extraites du symbole et des identifiants identifiant le dispositif à touches (100), et à utiliser des informations relatives à la session pour associer le dispositif à touches (100) au profil de l'utilisateur. Lors d'une session ultérieure, l'utilisateur peut utiliser le dispositif à touches (100) pour photographier un autre code graphique affiché sur une partie publique d'un site pour accéder à son profil d'utilisateur. L'utilisateur physique (200) est de préférence authentifié sur le dispositif à touches (100) au moyen d'une identification biométrique (210) et/ou non biométrique (211). Les critères d'identification de l'utilisateur sur le dispositif à touches peuvent être fonction de l'application et peuvent être communiqués du serveur de réseau (400) au dispositif à touches (100) par le biais du code ou du symbole graphique.
PCT/EP2011/066361 2010-09-20 2011-09-20 Authentification WO2012038449A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP11758473.0A EP2619940A2 (fr) 2010-09-20 2011-09-20 Authentification

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 (fr) 2012-03-29
WO2012038449A3 WO2012038449A3 (fr) 2012-05-18

Family

ID=44658759

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2011/066361 WO2012038449A2 (fr) 2010-09-20 2011-09-20 Authentification

Country Status (2)

Country Link
EP (1) EP2619940A2 (fr)
WO (1) WO2012038449A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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 (fr) * 2008-12-12 2010-06-17 Nec Europe Ltd. Dispositif de vérification mobile universelle

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None

Cited By (1)

* Cited by examiner, † Cited by third party
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
WO2012038449A3 (fr) 2012-05-18
EP2619940A2 (fr) 2013-07-31

Similar Documents

Publication Publication Date Title
US12081545B2 (en) Out-of-band authentication to access web-service with indication of physical access to client device
CN106464673B (zh) 用于验证装置注册的增强的安全性
US8485438B2 (en) Mobile computing device authentication using scannable images
EP2937805B1 (fr) Système d'authentification de proximité
CN112425114B (zh) 受公钥-私钥对保护的密码管理器
CN112425118B (zh) 公钥-私钥对账户登录和密钥管理器
US9628460B2 (en) Method of controlling access to an internet-based application
KR20180117715A (ko) 개선된 보안성을 갖는 사용자 인증을 위한 방법 및 시스템
US20090265769A1 (en) Method for automatically generating and filling in login information and system for the same
KR20110081103A (ko) 보안 트랜잭션 시스템 및 방법
WO2015188426A1 (fr) Procédé, dispositif, système, et dispositif associé, d'authentification d'identité
KR20150093781A (ko) 리소스 요청에 대한 바코드 인증
US10972465B1 (en) Secure authentication through visual codes containing unique metadata
CN116529729A (zh) 用于获得基于网络的资源的增强权限并根据其执行动作的集成电路
WO2016013924A1 (fr) Système et procédé d'authentification mutuelle faisant intervenir des codes à barres
WO2012038449A2 (fr) Authentification
WO2016042473A1 (fr) Authentification sécurisée à l'aide d'un code secret dynamique
US20180332028A1 (en) Method For Detecting Unauthorized Copies Of Digital Security Tokens
EP3570518B1 (fr) Systeme et procede d'authentification utilisant un jeton a usage unique de duree limitee
Matei-Dimitrie Multi-factor authentication. An extended overview
JP2021093063A (ja) 情報処理装置、認証システム、情報処理方法、および認証方法
JP2004021591A (ja) 管理装置及び認証装置

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