NL2035471B1 - Improved system for secure transmission of authentication data - Google Patents
Improved system for secure transmission of authentication data Download PDFInfo
- Publication number
- NL2035471B1 NL2035471B1 NL2035471A NL2035471A NL2035471B1 NL 2035471 B1 NL2035471 B1 NL 2035471B1 NL 2035471 A NL2035471 A NL 2035471A NL 2035471 A NL2035471 A NL 2035471A NL 2035471 B1 NL2035471 B1 NL 2035471B1
- Authority
- NL
- Netherlands
- Prior art keywords
- client device
- authentication data
- data
- primary client
- primary
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0827—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving distinctive intermediate devices or communication paths
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/36—User authentication by graphic or iconic representation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Some embodiments are directed to a system for secure transmission of authentication data from a secondary client device to a server application. The system may 5 include a primary client device, a secondary client device, and/or a relay server. The primary client device may encode a cryptographic key into a data packet. The secondary client device encrypts the authentication data using the key, and causes the authentication data to be sent to the primary client device. 10 (Figure 2a)
Description
IMPROVED SYSTEM FOR SECURE TRANSMISSION OF AUTHENTICATION DATA
The presently disclosed subject matter relates to a system for secure transmission of authentication data from a secondary client device to a server application, a primary client device, a secondary client device, a relay server, a primary client method, a secondary client method, a relay method, and a computer readable medium.
US patent application US2016373428 A1 discloses a known system using QR codes in a login procedure.
The known system allows a user to use a mobile device such as a smartphone to scan a QR (Quick Response) code displayed on a login webpage of a website. The QR code encodes a server URL (Uniform Resource Locator) for the website. The user scans the QR code with the mobile device. The mobile device decodes the QR code to obtain the server URL encoded in the QR code. The mobile device may transmit a device ID of the mobile device to the server URL. The server verifies that there are login credentials linked to the device ID. The server grants the user access to the website based on the linked login credentials.
The mobile device may also supply identification information of the mobile device to a service provider that stores multiple login credentials of the user for multiple sites. The service provider locates login credentials of the user linked to the device identification information for a website identified by the mobile device. The service provider communicates the login credentials of the user to a server of the website for the server to authenticate the user.
In other words, login credentials for a user are stored either at the web server itself or at a service provider. In both cases, the login credentials are released if the mobile device is recognized from its device ID.
It would be advantageous to have an improved authentication system. A system for secure transmission of authentication data from a secondary client device to a server application, a primary client device, a secondary client device, a relay server, a primary client method, a secondary client method, a relay method, and a computer readable medium are set out in independent claims. Specific embodiments of the invention are set forth in the dependent claims.
A system is provided comprising a primary client device and a secondary client device. The primary client device connects to a server application. For example, a user may interact with the server application using the primary client device. It may be needed for the primary client device to provide authentication data to the server application. For example, the server application may request authentication data, e.g., before allowing further interaction.
To obtain the authentication data, the primary client device creates a data packet comprising a cryptographic key. The primary client device transfers the data packet to the secondary client device through a direct transmission channel to the secondary client. The secondary client device obtains the data packet from the direct transmission channel from the primary client device and decodes the data packet to derive the cryptographic key.
The key is then used by the secondary client device to encrypt authentication data.
The encrypted authentication data is then sent to the primary client device, where it is decrypted and provided to the server application. Interestingly, as the key is provided from the primary client device to the secondary client device the authentication data cannot be read while in transit to the primary client device. In fact, in an embodiment, the authentication data is sent from the secondary client device to the primary client device through a relay server. Using a relay server simplifies connections considerably. With a relay server no direct connection between two user devices is needed any more. For example, if a firewall is used in the network of the primary client device, using the relay server helps to still send information from the secondary client device to the primary client device.
A direct transmission channel is a communication channel that facilitates data transmission between two computing devices, in particular a desktop computer and a mobile phone, without the intervention of any intermediate device or network.
For example, a direct transmission channel may comprise an optical communication channel. For example, the channel may comprise for the primary client device encoding the data packet, in particular the cryptographic key, into a data image, displaying the data image on a display of the primary client device, and on the other end of the channel for the secondary client device obtaining with a camera of the secondary device the data image from the display of the primary client device, and decoding the data image to derive the data packet, in particular the cryptographic key. For example, the data image may comprise a QR code.
For example, a direct transmission channel may comprise near field communication (NFC). In this instance, the primary and secondary client device may be enabled for NFC to establish communication by bringing them within close proximity of each other.
A direct transmission channel has the advantage that eavesdropping on the communication is much harder and typically requires proximity of the eavesdropper to the communicating devices. Communication channels that are not direct and that use intermediate devices or networks for transmission, such as Local Area Networks (LAN), Wide Area Networks (WAN), the internet, or any other form of relayed communication system may be eavesdropped upon at other devices than the primary and secondary device.
In an embodiment, the direct transmission channel comprises the use of light, e.g., a data image on a display, or possibly beamed light, e.g., infrared communication, or short-range electric field communication, e.g., having a range of less than 10 cm, such as NFC. In an embodiment, sound waves may be used for the direct communication channel. For example, the primary client device may comprise a speaker configured to transmit sound waves that encode the data packet, while the secondary client device comprises a microphone to receive the sound waves and is configured to decode them. The sound waves may be human audible, or may comprise ultrasound waves.
In an embodiment, the secondary client device does not send data to the server application directly, but uses the primary client device for this; the server application device could be completely agnostic of the login procedure used. From the perspective of the server application, it may appear that the primary client device provides the authentication data, e.g., that login credentials are typed in by a user, whereas in fact, the authentication data is provided by the secondary client device.
The authentication data could be locally stored at the secondary client device, but an advantageous option is to generate the authentication data at the secondary client device only when needed. For example, the authentication data could be generated from a server application identification, e.g., atop level domain or the like, and possibly a secret element that may be locally stored or input by the user, e.g., a secret phrase, pin code, or the like. The same secret element may be used for multiple different server applications. For example, the secret element comprises at least 10 bytes, preferably, at least 20 bytes.
The server application identification may comprise an identifier that identifies the server application, e.g., distinguishes the server application from other server applications for which the authentication system may be used. The server application identification may comprise a URL, TLD, and/or other computer addresses. The server application identification could comprise a string, e.g., a name of the server application, e.g., a Distinguished Name (DN) as defined in X.509.
For example, a seed may be generated from at least the server application identification. The seed may be used to generate an ephemeral public/private key pair. The public/private key pair may in turn be used to generate the authentication data. This authentication data could comprise a password, but the generated private key could also be used to sign a data item, e.g., a nonce generated by the server application and/or the primary client device.
The primary client device, secondary client device, server, and relay server are electronic devices. They may comprise, e.g., a computer. The primary client device may be a desktop computer, set-top box, laptop, or the like. The secondary client device may be a mobile electronic device, e.g., a mobile phone, tablet, etc. In an embodiment, the secondary client comprises a camera.
Authentication according to an embodiment described herein may be applied in a wide range of practical applications. Such practical applications include authentication for a blockchain application, e.g., to a blockchain interface device, or even to a miner directly, to a web server, or to a cloud application, etc.
Some embodiments are directed to a system for secure transmission of authentication data from a secondary client device to a server application. The system may include a primary client device, a secondary client device, and/or a relay server. The primary client device may encode a cryptographic key into a data packet. The secondary client device encrypts the authentication data using the key, and causes the authentication data to be sent to the primary client device.
Further aspects include methods for the primary client device, secondary client device and relay server. An embodiment of a method may be implemented on a computer as a computer implemented method, or in dedicated hardware, or in a combination of both. Executable code for an embodiment of the method may be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Preferably, the computer program product comprises non- transitory program code stored on a computer readable medium for performing an embodiment of the method when said program product is executed on a computer.
In an embodiment, the computer program comprises computer program code adapted to perform all or part of the steps of an embodiment of the method when the computer program is run on a computer. Preferably, the computer program is embodied on a computer readable medium.
Another aspect of the presently disclosed subject matter is a method of making the computer program available for downloading. This aspect is used when the computer program is uploaded, and when the computer program is available for downloading.
Further details, aspects, and embodiments will be described, by way of example only, with reference to the drawings. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. In the figures, elements which correspond to elements already described may have the same reference numerals. In the drawings,
Figure 1a schematically shows an example of an embodiment of an authentication system,
Figure 1b schematically shows an example of an embodiment of an authentication system,
Figure 1c schematically shows an example of an embodiment of an authentication system,
Figure 24 schematically shows a sequence diagram according to an example of an embodiment of an authentication system,
Figure 2b schematically shows a sequence diagram according to an example of an embodiment of registering a primary client device at a relay server,
Figure 2c schematically shows a sequence diagram according to an example of an embodiment of an authentication system,
Figure 3a schematically shows a computer readable medium having a writable part comprising a computer program according to an embodiment,
Figure 3b schematically shows a representation of a processor system according to an embodiment.
Reference signs list
The following list of references and abbreviations corresponds to the figures and is provided for facilitating the interpretation of the drawings and shall not be construed as limiting the claims. 100, 101, 102 an authentication system 110, 110.1, 110.2 a primary client device 120,120.1,120.2 a secondary client device
130, 130.1, 130.2 a relay server 140, 140.1, 140.2 a server 111,121, 131, 141 a processor system 112,122, 132, 142 storage 5 113, 123, 133, 143 communication interface 172 a computer network 201, 202, 203 an authentication system 210, 213, 215, 217 a message 219, 220, 221, 227 211, 214, 216, 218 processing 212 a transfer operation 1000, 1001 a computer readable medium 1010 a writable part 1020 a computer program 1110 integrated circuit(s) 1120 a processing unit 1122 a memory 1124 a dedicated integrated circuit 1126 a communication element 1130 an interconnect 1140 a processor system
While the presently disclosed subject matter is susceptible of embodiment in many different forms, there are shown in the drawings and will herein be described in detail one or more specific embodiments, with the understanding that the present disclosure is to be considered as exemplary of the principles of the presently disclosed subject matter and not intended to limit it to the specific embodiments shown and described.
In the following, for the sake of understanding, elements of embodiments are described in operation. However, it will be apparent that the respective elements are arranged to perform the functions being described as performed by them.
Further, the subject matter that is presently disclosed is not limited to the embodiments only, but also includes every other combination of features described herein or recited in mutually different dependent claims.
Figure 1a schematically shows an example of an embodiment of a primary client device 110, an embodiment of a secondary client device 120, an embodiment of a relay server 130, and an embodiment of server 140.
Primary client device 110, secondary client device 120 may be part of an authentication system 100. The authentication system 100 may further comprise an optional relay server 130. The authentication system 100 may further comprise server 140.
Primary client device 110 is configured to connect to a server application running on server 140. For example, primary client device 110 may provide a user interface for the server application. The connection between primary client device 110 and the server application, e.g., to provide an interactive user interface, may use protocols such as HTTP or HTTPS. Connecting to the server application may use an authentication protocol such as OpenID connect, SAML, LDAP protocol. The authentication protocol between primary client device 110 and server application may require authentication data, e.g., one or more of : login credentials, a password, username, biometrics. The authentication data may also comprise a challenge response element. For example, a symmetric or asymmetric signature over a nonce provided by the server application to the primary client device 110. Connecting to the server application may be done later, e.g., after the encrypted authentication data has been received.
An authentication needed for the server application is fulfilled using secondary client device 120, possibly using relay server 130 as a relay between primary client device 110 and secondary client device 120.
Secondary client device 120 is configured to obtain the authentication data, e.g., to generate or retrieve it, and to send the authentication data to the primary client device. The primary client device in turn can use the authentication data to authenticate to the server application.
Relay server 130 is configured to allow communication between the primary client device 110 and the secondary client device 120. Interestingly, in an embodiment the relay server does not gain access to the authentication data, as the authentication data is encrypted with a key inaccessible to the relay server. Relay server 130 is not strictly necessary, but provides advantages to the system. For example, relay server 130 simplifies communication between the primary client device and the secondary client device. Furthermore, different users of the system, e.g., different instances of the authentication system may use their own relay server which in turn allows the relay server to provide additional services.
Server 140 is configured to host a server application that may be used over a computer network at the primary client device. For example, the server application hosted by server 140 may comprise a web server. For example, the primary client device may comprise a web browser interfacing with the web server. Instructions for the web browser to perform the operations of the primary client device. For example, the instructions for the web browser may be contained in a so-called browser extension. For example, the instructions for the web browser may be contained in a website page, e.g., a web application. The web application may comprise
JavaScript code or the like to implement the instructions.
For example, the server application may comprise a blockchain interface. The primary client device's operations may include sending a command to the blockchain interface.
The blockchain interface’s operations may include sending a transaction to a blockchain miner for inclusion in a block of the blockchain.
Primary client device 110 may be a device that is primarily used by a userto interface with the server application. It may be required to provide authentication data to the server application to authenticate the user. For example, the server application may send a request for authentication data, or some operations may require authentication data to be sent with it.
The primary client device 110 may not have authentication data stored, and/or may not have the ability to generate authentication data locally. Primary client device 110 may use the secondary client device 120 to do so, however. Primary client device 110 may generate a data packet, comprising information needed by the secondary client to obtain the authentication data, e.g., to retrieve or generate the authentication data. Furthermore, the data packet also contains a cryptographic encryption key. The secondary device may use the cryptographic encryption key to encrypt the authentication data and cause the encrypted data to be sent to the primary server.
Using this key avoids leaking of the authentication data. The data packet may be encoded in a data image, typically a QR code. Other direct transmission channels may be used.
Interestingly, a relay server 130 may be included in the authentication system. Relay server 130 may receive the encrypted authentication data from the secondary client device 120.
Relay server 130 is configured to further communicate the data to the primary client device.
Using a relay server 130 is not necessary but has various advantages. Arranging communication between two client devices may not be robust. The relay server may provide store data temporarily, acting as a buffer in case of network disruptions or varying data processing speeds between devices. Furthermore, the relay server may be scaled up or down easily, accommodating for an increase or decrease in the number of primary and/or secondary client devices. The relay server may further enhance data security, e.g., the relay server may further encrypt the data transmission between the primary and secondary client devices, further protecting the data from interception during transmission. Moreover, the relay server may authenticate primary client device 110, e.g., verify that it is entitled to receive the data. This could be done e.g., when the primary client device 110 registers to the relay server, thus enhancing security. The verification and/or authentication may also/or instead be done for secondary client device 120 by relay server 130.
The optional relay server may be used for additional tasks. For example, the relay server may be configured to queue messages if the primary client device is not currently available or connected. The relay server may be used to navigate around firewalls, acting as an intermediary that establishes connections that the devices themselves may not be able to, or not easily be able to. Relay server 130 may be configured to monitor network traffic and perform analytics for further optimization and troubleshooting.
Primary client device 110 may comprise a processor system 111, a storage 112, and a communication interface 113. Secondary client device 120 may comprise a processor system 121, a storage 122, and a communication interface 123. Relay server 130 may comprise a processor system 131, a storage 132, and a communication interface 133. Server 140 may comprise a processor system 141, a storage 142, and a communication interface 143.
Primary client device 110, e.g., communication interface 113, and secondary client device 120, e.g., communication interface 123, may be configured for a direct communication channel between them.
Primary client device 110 may further comprise a display (not separately shown in figure 1a) which is arranged to display a data packet in the form of a data image such as a QR code. Secondary client device 120 may then further comprise a camera (not separately shown in figure 1a) which is arranged to capture a data image such as a QR code.
Primary client device 110 may further comprise an NFC unit, e.g., an NFC transmitter, (not separately shown in figure 1a) which is arranged to transfer the data packet over NFC communication. Secondary client device 120 may then further comprise an NFC unit, e.g., an
NFC receiver {not separately shown in figure 1a) which is arranged to receive the data packet.
An NFC unit is also referred to as an NFC element.
In an embodiment, multiple direct transmission channels are combined. For example, in an embodiment, the primary client device is configured to split the data packet into at least two parts, each part being transferred over a separate direct transmission channel. The data packet parts are reassembled at the secondary client to recreate the original data packet, e.g. cryptographic key.
The split parts of the data packet may be created such that no single part contains sufficient information to infer the cryptographic key without the other part(s). For example, a secret sharing scheme or similar cryptographic technique may be used. For example, a data packet X may be split into n parts, by choosing parts X; up to X,,_, at random, and the final part X,, as the
XOR of X and parts X, up to X,,_,. In this case the parts have the same size as the original data packet X. In an embodiment, data, e.g., a header, may be added to the parts X, up to X,, to identify them as a part. Other secret sharing schemes may be used.
Using multiple different direct transmission channels has the advantage that the system is more secure in case one of the direct transmission channels is compromised. For example, an optical transmission channel may be combined with an NFC channel. For example, an optical transmission channel may be combined with an NFC channel and a sound channel.
In an embodiment, the data packets or data packets parts are encrypted by the primary client device using an encryption key for which the secondary client device has the corresponding decryption key. The secondary client device decrypts the data packet or data packet parts with the decryption key. For example, the encryption and decryption key may be the same symmetric key. For example, encryption and decryption key may be part of an asymmetric key. The decryption key or the encryption key may be shared by the primary client device or the secondary device during a previous set-up phase. Although the use of a long-term key has drawbacks, the security of a long-term key complements the use of the cryptographic key in the data packet.
Typically, primary client device 110 is a desktop computer. Typically, secondary client device 120 is a mobile computer, such as a smartphone, tablet, or the like. The secondary client may be an embedded device, e.g., an ASIC device.
In the various embodiments of communication interfaces 113, 123, 133, and/or 143, the communication interfaces may be selected from various alternatives. For example, the interface may be a network interface to a local or wide area network, e.g., the Internet, a storage interface to an internal or external data storage, an application interface (API), etc.
Storage 112, 122, 132, and 142 may be, e.g., electronic storage, magnetic storage, etc. The storage may comprise local storage, e.g., a local hard drive or electronic memory.
Storage 112, 122, 132, and 142 may comprise non-local storage, e.g., cloud storage. In the latter case, storage 112, 122, 132, and 142 may comprise a storage interface to the non-local storage.
Storage may comprise multiple discrete sub-storages together making up storage 112, 122, 132, and 142.
Storage 112, 122, 132, and 142 may be non-transitory storage. For example, storage 112,122,132, and 142 may store data in the presence of power such as a volatile memory device, e.g., a Random Access Memory (RAM). For example, storage 112, 122, 132, and 142 may store data in the presence of power as well as outside the presence of power such as a non-volatile memory device, e.g., Flash memory. Storage may comprise a volatile writable part, say a RAM, a non-volatile writable part, e.g., Flash, Storage may comprise a non-volatile non-writable part, e.g., ROM.
The devices 110, 120, 130, and 140 may communicate internally, with each other, with other devices, external storage, input devices, output devices, and/or one or more sensors over a computer network. The computer network may be an internet, an intranet, a LAN, a WLAN, etc. The computer network may be the Internet. The devices 110, 120, 130, and 140 may comprise a connection interface which is arranged to communicate within authentication system 100 or outside of authentication system 100 as needed. For example, the connection interface may comprise a connector, e.g., a wired connector, e.g., an Ethernet connector, an optical connector, etc., or a wireless connector, e.g., an antenna, e.g., a Wi-Fi, 4G or 5G antenna.
The communication interface 113 may be used to send or receive digital data, e.g., to receive an authentication request and/or send authentication data to server 140. The communication interface 123 may be used to send or receive digital data, e.g., send encrypted authentication data. The communication interface 133 may be used to send or receive digital data, e.g., receive and send encrypted authentication data. The communication interface 143 may be used to send or receive digital data, e.g., to communicate with primary client device 110, e.g., to receive authentication data and/or to interact to support the server application. For example, the server application may comprise a web server. Server 140 may interact with primary client device 110 to allow a user to interact with the server application.
Primary client device 110 and secondary client device 120 may have a user interface, which may include well-known elements such as one or more buttons, a keyboard, display, touch screen, etc. The user interface may be arranged for accommodating user interaction with the server application. For example, in case of a web server, browsing the browsing application implemented at the web server. For example, in case of a blockchain interface, making a transaction, e.g., transferring a cryptocurrency amount, or initiating a smart contract or the like.
The execution of devices 110, 120, 130, and 140 may be implemented in a processor system. The devices 110, 120, 130, and 140 may comprise functional units to implement aspects of embodiments. The functional units may be part of the processor system. For example, functional units shown herein may be wholly or partially implemented in computer instructions that are stored in a storage of the device and executable by the processor system.
The processor system may comprise one or more processor circuits, e.g., microprocessors, CPUs, GPUs, etc. Devices 110, 120, 130, and 140 may comprise multiple processors. A processor circuit may be implemented in a distributed fashion, e.g., as multiple sub- processor circuits. For example, devices 110, 120, 130, and 140 may use cloud computing.
Typically, the primary client device 110, secondary client device 120, relay server 130, and server 140, each comprise one or more microprocessors which executes appropriate software stored at the device; for example, that software may have been downloaded and/or stored in a corresponding memory, €.9., a volatile memory such as RAM or a non-volatile memory such as Flash.
Instead of using software to implement a function, the devices 110, 120, 130, and/or 140 may, in whole or in part, be implemented in programmable logic, e.g., as field-programmable gate array (FPGA). The devices may be implemented, in whole or in part, as a so-called application-specific integrated circuit (ASIC), e.g., an integrated circuit (IC) customized for their particular use. For example, the circuits may be implemented in CMOS, e.g., using a hardware description language such as Verilog, VHDL, etc. In particular, devices 110, 120, 130, and 140 may comprise circuits, e.g., for cryptographic processing, and/or arithmetic processing.
In hybrid embodiments, functional units are implemented partially in hardware, e.q., as coprocessors, e.g., cryptographic coprocessors, and partially in software stored and executed on the device.
Figure 1b schematically shows an example of an embodiment of an authentication system 101.
The system may comprise multiple primary client devices, shown are primary client devices 110.1 and 110.2. For example, the same user may use multiple primary client devices, e.g., with one secondary client device. For example, one or more of the multiple primary client devices may be used by different users, and different secondary client devices.
The system may comprise multiple secondary client devices, shown are secondary client devices 120.1 and 120.2. For example, multiple users may use the authentication system, each with its own secondary client device. Different users may use the same primary client device, with different secondary client devices. A user may use multiple secondary client devices, e.g., configured for the same or different authentication data.
The system may comprise multiple relay servers, shown are relay servers 130.1 and 130.2. For example, different organizations may prefer to use their own relay servers. For example, one or more servers may provide a relay server to accommodate secure providing of authentication data.
The system may comprise multiple servers, shown are servers 140.1 and 140.2. For example, different server applications may run on a different server. A server may be used by multiple users, each with at least one secondary client device.
The primary client devices, secondary client devices, relay servers, and servers may each be connected to a computer network 172, e.g., the Internet. Typically, secondary client device 120 will use a wireless connection, while the other devices typically use a wired connection.
Multiple computer networks may be used.
Figure 1c schematically shows an example of an embodiment of an authentication system 102. Secondary client device 120 is connected to Relay server 130 over a computer network connection. Relay server 130 is connected to primary client device 110 over a computer network connection. Primary client device 110 is connected to server 140 over a computer network connection.
In figures 1b and 1c, relay server 130 is optional.
Relay server 130 may be a single device or implemented as a distributed system, e.g., geographically distributed. Server 140 may be a single device or implemented as a distributed system, e.g., geographically distributed.
Figure 2a schematically shows a sequence diagram according to an example of an embodiment of an authentication system 201. The sequence diagrams according to figures 2a- 2c may be implemented on electronic devices, e.g., computers. The sequence diagrams according to figures 2a-2c may be implemented on the electronic devices according to figure 1a.
In the sequence diagrams time progresses in the direction from top to bottom.
System 201 is configured for the secure transmission of authentication data from a secondary client device to a server application. This avoids the need to store the authentication data on the primary client device. This is both convenient as it allows the same authentication data to be used on multiple primary client devices. It is also secure, as the authentication data needs to be present on the primary client device for only a short duration.
The embodiments are described with reference to a primary client device 110, secondary client device 120, relay server 130, and a server 140. Many options, although beneficial, are optional.
Primary client device 110 is configured to connect to a server application running on server 140 and provide authentication data to it. For example, server 140 may send a message 140 requesting authentication data. Alternatively, primary client device 110 may send authentication data without a request, e.g., along with a command sent to the server application.
Before or during message 210, device 110 may provide a user interface to the server application, e.g., for a user of primary client device 110. Typically, the user of primary client device 110 is the same as the user of secondary client device 120.
To provide the authentication data, in processing 211, the primary client device may collect information and use it to generate a data packet.
Primary client device 110 generates a cryptographic key, e.g., a cryptographic encryption key. Various options are possible for this. The cryptographic encryption key may be a symmetric key, e.g., a block cipher key, such as an AES key. The key length may be at least 80 bits, at least 128 bits, etc. The key may be a one-time pad. The key may be an asymmetric key, e.g., a public key of a public/private key pair. For example, the public key may be an RSA type key, or an ECC key, e.g., using the Elliptic Curve Encryption Scheme.
Preferably, the key is an ephemeral key, e.g., generated for this transfer of authentication data. For example, a secure random generator may be used to generate the key.
The primary client also generates a decrypting key corresponding to the encryption key. For a symmetric key, the decrypting key may be the same as the encryption key. For an asymmetric key, the encryption key may be the public key from a public/private key pair, while the decryption key is the private key.
Primary client device 110 stores the decryption key at least until the encrypted authentication data is decrypted in processing 218, after which it is preferably deleted from device 110. Primary device 110 is configured to temporarily store the key, e.g., in RAM, so that later the key is available to decrypt the authentication data.
Optionally, Primary client device 110 may generate a nonce. For example, the nonce may be at least 64 bits, at least 80 bits, or at least 128 bits, etc. The nonce may be generated with a secure random generator. The nonce will reduce the risk that a malicious actor could repeat an earlier message recorded from an authentic secondary client device.
A first nonce may be generated by the primary client device. A second nonce may be generated by the server application. In the latter case, the nonce may play a role in the generation of the authentication data. Accordingly, a first nonce and/or a second nonce may be used. Both nonces are optional. Use of the second nonce depends on how the server application is arranged.
Further data may be collected by device 110.
For example, the further data may comprise a computer address allowing the secondary client device to send data to relay server 130, e.g., a URL; an identification of the server application.
For example, the further data may comprise an identification of the server application.
For example, this may comprise a computer address, e.g., a URL, e.g., the top level domain (TLD) part of the URL of the server application. The identification may be the TLD of a website that needs authentication data. For example, the URL login.facebook.com has as TLD facebook.com.
The identification need not comprise a computer address. For example, relationship between identifier and server application may be predetermined and known to the secondary client device. For example, identifier 123 may refer to the ABC Bank, etc.
For example, the further data may comprise an identification of the user of the server application. For example, this may be the user that is associated with the authentication data.
This information is optional, as the username may be known by the secondary client device.
For example, the further data may comprise a signature over the included data with a private key of the primary client device, for which the secondary client device has a signature.
For example, the further data may include a session identifier (session ID), that allows the primary client device and/or the relay server to identify the correct authentication session for which the authentication data is intended. The session identifier may be randomly generated. The session identifier and first nonce may be the same. Instead of a session identifier, or in addition, a connection identifier may be included in the data packet.
For example, the following information may be collected by the primary client device: - cryptographic encryption key - nonce, e.g., a first nonce generated by the primary client device, and/or a second nonce generated by the server application,
- computer address of relay server - server application identification - user identification, e.g., username - session identifier. - signature over the data above,
The data may be encoded in a binary object, using any of a variety of conventional means to do so, e.g., XML, JSON, as a struct or packed data, ASN.1 coded, protobuf coded, etc.
The binary object may also include a checksum, and/or error correction information.
The collected data, e.g., the binary object, is then encoded in a data packet which is transferred in a direct communication channel at message 213.
For example, the primary client device may translate the binary object into a set of visually representable data patterns, and generate a data image based on said visually representable data patterns. A typical example of such a data image is a QR code. Other examples include barcodes, data matrix codes, and High Capacity Color Barcode (HCCB).
Primary client device 110 then transfers at 212 the data packet. For example, device 110 may display the image on a display of the primary client device. For example, the display may be a monitor, or the like. The data image may be accompanied with instructions to the user to start the process of sending authentication data to the primary client device, including capturing the data image.
The secondary client device 120 captures the data image from the display of device 110, and thus receives its content in message 213. In processing 214, the secondary client device 120 decodes the data image to derive the information encoded therein. For example, the user may start an application, e.g., an app, e.g., on a smartphone. The app may cause a camera of the secondary client device to capture the data image from the display.
Secondary client device 120 decodes the captured data image to obtain the information included therein, e.g., the data packet. In this way secondary client device 120 obtains the cryptographic key.
Instead of transferring the data packet through an optical channel in the form of a data image, other direct transmission channels may be used. For example, the primary client device may send the data packet through nfc communication to the secondary client device. After receiving the data packet, processing may be similar to the processing of a data image.
Secondary client device 120 then obtains the authentication data, encrypts the authentication data with the key obtained from the data image, and causes the authentication data to be sent to the primary client device. Obtaining the authentication data can be done in various ways. Sending the authentication data to the primary client device can be done in various ways. Secondary client device 120 may also perform additional processing.
From the data packet, secondary client device 120 may obtain additional information, e.g., the list of data items or part thereof shown above for the primary client device 110.
For example, the authentication data may comprise a password. The password may be generated, e.g., from other information, e.g., including one or more of: a server application identification, a secret element, and/or username, and the like. The secret element may be locally stored. Using a secret element in addition to other information reduces the likelihood that a malicious party could generate the authentication data without access to the secondary client device.
For example, the authentication data, e.g., a password may be locally stored on the secondary client device. For example, the password may be externally stored, e.g., in a password management service, and retrieved by the secondary client device.
Authentication data could also comprise further or alternative elements than a password. For example, the authentication data could comprise a signature over a second nonce produced by the server application. Obtaining the authentication data may comprise signing a challenge.
Obtaining the authentication data may comprise generating a password. For example, the secondary client may generate a password, or other cryptographic token, that the server application can verify as authentic.
Obtaining the authentication data may comprise generating a unique token, the token may comprise one or more of a unique ID, a serial number, a timestamp. The token is then signed using a private key accessible at the secondary client device. The server application may verify the authenticity of the signed token by verifying the signature and the freshness of the token’s content.
Authentication data could also comprise further or alternatively, biometric data, e.q., stored or collected at the secondary client device; security tokens stored or generated at the secondary client device, e.g., security tokens, e.g., hardware or software tokens that store information used to authenticate users. RSA SecurlD tokens are an example.; tickets, e.g.,
Kerberos tickets, etc.
Authentication data may comprise a signature over the second nonce, and possibly further data, e.g., one or more of: a first nonce, server application identification, username, timestamp, etc. The authentication data could be accompanied or include a public key certificate with which the signature may be verified.
In an embodiment, generating authentication data comprises generating a seed from at least the identification of the server application, e.g., the TLD, and possibly other data that identifies this authentication session, e.g., a username. The authentication data may then be derived from the seed, e.g., using a key derivation function. Key derivations are described, e.g., in RFC 5869, or OMA DRM Specification V2.0, e.g., OMA-DRM-DRM-V2_0-20040420-D (KDF function in section 7.1.2), etc. Generating the seed may also depend on one or more secret element, e.g., stored and/or input at the primary client device and/or secondary client device.
A particularly advantageous way to generate the authentication data is to generate a cryptographic public/private key pair using a pseudo random generator seeded by the seed. For example, the key pair could be an RSA key pair, or an ECC key pair, e.g., an ECDSA key pair, etc. The public key of the pair may then be used to derive the authentication data from. For example, by applying a key derivation function to the public key to derive the authentication data.
For example, from server identification and possibly other data, a seed is derived, e.g., with a first key derivation function. From the seed a public/private key is derived. From the public key the authentication data is derived, e.g., using a second key derivation function.
A key derivation function can be created through the function composition of a hash function, possibly a keyed hash function, and a generation function. The generation function generates a key pair or authentication data according to requirements, e.g., the specified requirements of the server application.
In an embodiment, authentication data is derived from a public key, e.g., using a key derivation function, wherein the public key is derived from the seed. A signature is computed over the authentication data using a private key. For example, the private key corresponds to the generated cryptographic public key from which the authentication data is derived.
For example, the private key may correspond to a previously generated cryptographic private key; for example, a public key certificate may be stored at the primary client device to verify the signature.
If one or more nonces were provided in the data packet the signature may be computed over them as well.
The public key derived from the seed, and from which the authentication may be derived in turn, may be sent together with the authentication data, so that the primary client device obtains the public key. The primary client device may use the public key to verify a signature over the authentication data. The public key may then be used by the primary client device to establish a secure communication channel between them using the public key. For example, the primary client device and second client device may execute a key agreement protocol, e.g., a Diffie-
Hellman protocol.
In an embodiment, the secondary client device derives a seed from at least the server application identification, e.g., a TLD. From the seed a public/private key is derived. From the public the authentication data is then derived. The public key is sent to the primary client device and may be sent to the server application. By comparing the public key with previously received public keys, it can be verified whether the authentication data corresponds to a previously registered account, or a new account. In the latter case, e.g., if a new public key is received, the server application may prompt to create a profile. The public key may also be used for secure communication with the second client device. Deriving the authentication data from the public key may be done by a key derivation function, e.g., a hash function, or keyed hash function. The authentication data may also or instead be derived from the private key; in this case the authentication data may comprise a signature over a nonce, e.g., the second nonce.
The secondary client device may obtain from the data packet the computer address of the relay server 130. This is not necessary; the relay server address may already be known at the secondary client device. The encrypted authentication data may then be sent to the computer address for forwarding to the primary client device. The secondary client may include further data, e.g., a session identifier, that allows the primary client device and/or the relay server to identify the correct authentication session. Other options are possible, and discussed herein.
The secondary client device may further obtain a universally unique identifier and send the universally unique identifier to the primary client device, e.g., via the relay server. The identifier may be derived by applying a key derivation function to the seed. The universally unique identifier may be used as a username, but may also be used for other applications, e.g., blockchain applications.
If the primary client device included a signature in the data packet, e.g., computed over the other data in the data packet, e.g., over the cryptographic key. The secondary client device may verify the signature. If the data includes further verifiable information, e.g., a timestamp, then these may also be verified by the secondary client device. If a verification, e.g., signature and/or timestamp, is rejected, then the secondary client device may refuse to send the authentication data.
As a non-limiting example, secondary client device may derive from the obtained data packet the following information - cryptographic encryption key - user identification, e.g., username - server application identification - a first nonce generated by the primary client device - computer address of relay server - session identifier - signature over the data above.
This data packet could be obtained in the form of a data image, a nfc communication, and/or other direct transmissions.
In this example, secondary client device may first verify the signature, then derive authentication data, e.g., from the server application identification and user identification, and encrypt the authentication data with the cryptographic encryption key. Then a signature may be computed over the encrypted authentication data, session identifier and first nonce. The encrypted authentication data, session identifier and signature may then be sent to the computer address of the relay server.
At message 215, secondary client device 120 causes the authentication data to be sent to the primary client device, in this embodiment by sending the authentication data to relay server 130.
In processing 216, relay server 130 receives from the secondary client device encrypted authentication data, and causes the encrypted authentication data to be forwarded to the primary client device in message 217.
This can be done in various ways. An advantageous solution is to use polling from the primary client device to the relay server. This option avoids firewall restrictions that may be a problem if the relay server were to attempt pushing the authentication data instead.
For example, the relay server may temporarily store the received encrypted authentication data together with the session identifier, or connection identifier (connection ID}; the connection identifier is further discussed with reference to figure 2b. When relay server 130 is polled, e.g., receives a request from the primary client device, the relay server may return the stored encrypted authentication data to the primary client device. If secondary client device 120 also sent a signature, then this may also be forwarded to primary client device. If secondary client device 120 also sent a session identifier, then this may also be forwarded to primary client device 110.
Instead of polling by device 110 other solutions are possible.
Additional authentication may be used, for example, primary client device and/or relay server may sign their messages, so that the other party may verify the origin of the message.
For example, the polling request of the primary client device may be signed, and/or the response of the relay server 130 with the encrypted authentication data may be signed. Signing may be asymmetrical, or symmetric, e.g., using Hmac.
When primary client device 110 receives the encrypted authentication data, encrypted by the secondary client from relay server 130, processing 218 starts. In processing 218 the primary client device decrypts the encrypted authentication data using the generated cryptographic key.
If additional verification data is included, then these may be verified. For example, a signature may be verified. For example, secondary client device 120 may have created a signature over data that includes in addition to the encrypted authentication data, also a nonce.
The signature may be verified as well as the nonce.
Primary client device 110 then sends the authentication data to the server application, in message 219.
It may happen that the server application is connected to the secondary client device, e.g., on a smartphone. This could be detected, e.g., on a website page, in which case the data packet generation, and transfer may be skipped. The secondary client may proceed with obtaining the authentication data and sending the authentication data to the server application. For example, in this case, the secondary client may be configured for the following: - connecting to the server application, - detecting that the connection is on a secondary client device, and if so, - obtaining the authentication data, - sending the authentication data to the server application,
If it is detected that the connecting is not on the secondary client device, but on a primary client device, then the device may proceed with generating a data packet, e.g., a data image and/or nfc transmission. Detecting that the connecting is on the secondary device may be done in a number of manners. For example, the secondary device may detect the availability of a local storage for authentication data, or a local library for the generation of authentication data, or may detect a local device identifier known from a list of secondary client device identifier, or may query the user, etc.
In an embodiment, a data image such as a QR may still be generated, so that a user can tap on the data image, e.g., a QR code, to access the server application. This may use a deep linking method based on the URI.
Figure 2b schematically shows a sequence diagram according to an example of an embodiment of an authentication system 202. Figure 2b shows a detail that may be used before message 213, or preferably before message 210, e.g., in a protocol as described with reference to figure 2a.
In message 210, the primary client device registers at relay server 130. For example, message 220 may contain an identification of primary client device 110, e.g., an identification number. Message 220 may also contain a public key of primary client device 110 if that public key is not yet available at relay server 130. Primary client receives 110 from relay server 130 a connection identifier. The connection identifier may be a number.
Primary client device may encode the connection identifier into the data packet.
Secondary client device 120 may then send the connection identifier to the relay server together with the authentication data. Relay server 130 stores the authentication data together with the connection identifier.
When later primary client device 110 polls relay server 130 it can include the connection identifier, which allows relay server 130 to look up the correct authentication data.
Other possibilities for relay server 130 to send information to primary client device 110 include:
WebSockets: This is a protocol that allows two-way communication between the relay server and the primary client device 110. Once a WebSocket connection is established, the relay server can send data to the primary client device 110 at any time.
Long Polling: In this approach, the primary client device 110 sends a request to the relay server 130 and waits for a response. The relay server 130 does not respond until it has data to send back to primary client device 110. Once primary client device 110 gets a response, it immediately sends another request, and the process repeats.
Figure 2c schematically shows a sequence diagram according to an example of an embodiment of an authentication system 203.
Authentication system 203 is similar to system 201 but omits the relay server. Up to processing 214 the two systems may be the same, except that no relay server computer address is included in the data packet but optionally a computer address for the primary client device that enable the secondary client device to send data. Message 215 is then sent to primary client device 110 as message 227.
Below further examples, embodiments, applications, and optional details are described. These examples assume a data packet is transferred through an optical direct transmission channel. Such examples may be modified to use another direct transmission channel in addition or instead of the optical transmission channel.
In an embodiment, a password manager is provided that provides a high level of authentication security, e.g., to protect identity. The password manager may create a unique password for each account and each website. The password need not be remembered or written down. In an embodiment, the password isn't stored on mobile phone, app, computer or external backend environment. This reduces the risk of attack and account take over.
A password generator may generate a password according to a domain name that is extracted. Encrypted credentials, e.g., username + password, may be sent to an endpoint that will may be decrypted by a browser extension.
The password generator may use generative, strong and deterministic passwords making it harder to brute force an account's password. A unique password may be generated for every service. Conventional password managers store passwords and thus provide an attack vector. An embodiment of the authentication system may be configured so that a password is not long-time stored, not even encrypted. For example, after generating, encrypting and sending authentication data, e.g., a password, the authentication data may be deleted.
Different password may be created for every different site and/or application.
Passwords may be complicated and not easy to guess. There is no need to remember them or store them in a safe place. No use of centralized systems is required. No personal data needs to be stored on a server or in the app.
An embodiment of the authentication system may include an AutoFill Extension for a web browser that enters account credentials of an app or website. The password generator may be used to securely transmit the user credentials to a desktop browser such as Chrome, Firefox,
Brave and Edge. The transmission may use TLS + Payload encryption using a one-time pad and secure key exchange via the QR code.
The QR may be displayed by the browser extension: First, the browser extension generates a secure cryptographic key, e.g., using a Cryptographically Secure Pseudo-Random
Number Generator (CSPRNG), e.g., a secure random generator, then the browser extension encodes the key into a URI, e.g., a callback URI set to a public/custom endpoint. When scanning the QR code, the mobile app has access to the secure key. Note that the key was never transmitted over a computer network. Furthermore, the mobile app now knows where to send the password. Instead of a browser extension other software, e.g., locally executed software, may be used.
For example, this may be used to autofill registration or login forms conveniently by a browser extension, by simply scanning a QR code. Scanning the QR code, e.g., the data image, is typically done on a phone of the user. The phone scans the QR code so that the cryptographic key, e.g., the one-time pad key, does not have to be transmitted, and thus, cannot be intercepted.
Before displaying the QR code, the browser extension may register itself at the relay server. The app extracts the connection identifier from the QR code and uses this to transmit the encrypted credentials back to the browser extension, via the relay server.
The underlying technology may use Transport Layer Security (TLS) to communicate with a relay server that forwards the credentials to the browser. Note that the browser extension generates the cryptographic key, e.g., one-time pad, and encodes that into the QR code. This reduces the trust in TLS certificates needed; For example, private endpoints could use self- generated certificates that would allow MITM-Attacks; these issues are reduced by using a cryptographic key generated by the desktop, e.g., the primary client device.
The cryptographic key generated by the browser extension may comprise a one-time pad. The cryptographic key may be used to encrypt the authentication data. This helps to ensure that no middleman can read the sensitive credentials as only the primary client device, e.g., a browser extension, and the secondary client device, e.g., a mobile app, share the encryption key.
The password may be created, but also re-created when needed, in various ways.
For example, to get a secure and deterministic seed for a random generator, one may use cryptographic technologies including, a hash function, e.g., SHA256, RIPEMD160, HASH160, and a key derivation function, e.g., BIP32, e.g., version of 4 Nov 2020. The seed may be computed by applying HASH160 to a public key. Hash160 is a function used in Bitcoin and comprises
RIPEMD160(SHA256($publicKey))). Using BIP32 it is possible to securely derive one or more keys from a seed.
For example, the password generator may use the seed as a root seed and use the domain + BIP32 to generate a private key. From the private key the password generator generates a public key, typically temporarily. For example, the private key may be an ECC private key, e.g., an Elliptic Curve Digital Signature Algorithm (ECDSA) key. ECDSA is a cryptographic algorithm for signing and verification of signatures. ECDSA private key are easy to generate, so this is a convenient choice. However, other types of private keys, such as signing keys, can be created from the seed as well. From the private key the corresponding public key is computed.
The generated private/public key pair may be temporary, e.g., they are only stored for so long as they are needed to complete sending the authentication data.
A hash is applied to the public key, e.g., a public key hash, e.g., HASH160. This public key hash may be used as a seed for the password. For example, a password generator function may take the password seed and derive a password from the seed that satisfies password constraints, e.g., consisting of a predetermined set of characters and having a minimum number of characters from certain sets, e.g., consisting of printable characters, and having upper and lower case letters, etc.
In summary, a way to generate or re-generate a password is as follows 1. Seed + domain + BIP32 -> Private Key 2. Private Key -> Temp Public Key -> HASH160 3. HASH160 -> Generate password
Note that no encryption or description is required, like conventional Password
Generator do.
In an embodiment, a unique password is created for each account and each website.
A user does not need to remember the password, and/or write it down. The password is not stored on a mobile phone, app, computer or backend environment. This reduces the risk of attack and
Account Take Over from the side of the user and the side of the server application.
In an embodiment, a private and public keys of a wallet is derived from a binary master seed (Tp and an ordered set of indices, e.g, a so-called BIFEZ path, For example, the mechanism described in BIP-0032 for creating a general structure of hisrarchival deterministic wallet eg, an HD walle! may be used, Bip-3Z, titled 'Hisrarchica! Deterministic Wallets’, by Pister
Wullie, lasti revised on 18 April 2013, is available, &.4., at hitps./aithub.com/bitcoin/bins/blob/master/bip-0032. mediawiki. Note in particular, the
Higrarchical Deterministic Wallet diagram.
Below examples of an embodiment of the methods are provided.
A primary client method, may comprise - connecting to the server application,
- providing authentication data to the server application, comprising - generating a cryptographic key, - encoding the cryptographic key into a data image, - displaying the data image on a display of the primary client device, - receiving encrypted authentication data, encrypted by the secondary client, and - decrypting the encrypted authentication data, and - sending the authentication data to the server application.
A secondary client method may comprise - obtaining with a camera of the secondary device the data image from the display of the primary client device, - decoding the data image to derive the cryptographic key, - obtaining the authentication data, e.g., signing a challenge, generating or retrieving a password, etc. - encrypting the authentication data, and - causing the authentication data to be sent to the primary client device.
A relay method may comprise - receiving from the secondary client device encrypted authentication data, and - forwarding the encrypted authentication data to the primary client device.
For example, these methods may be computer implemented methods.
Many different ways of executing the methods are possible, as will be apparent to a person skilled in the art. For example, the order of the steps can be performed in the shown order, but the order of the steps can be varied or some steps may be executed in parallel. Moreover, in between steps other method steps may be inserted. The inserted steps may represent refinements of the method such as described herein, or may be unrelated to the method. For example, some steps may be executed, at least partially, in parallel. Moreover, a given step may not have finished completely before a next step is started.
Embodiments of the method may be executed using software, which comprises instructions for causing a processor system to perform an embodiment of the methods. Software may only include those steps taken by a particular sub-entity of the system. The software may be stored in a suitable storage medium, such as a hard disk, a floppy, a memory, an optical disc, etc.
The software may be sent as a signal along a wire, or wireless, or using a data network, e.g., the
Internet. The software may be made available for download and/or for remote usage on a server.
Embodiments of the method may be executed using a bitstream arranged to configure programmable logic, e.g., a field-programmable gate array (FPGA), to perform an embodiment of the method.
It will be appreciated that the presently disclosed subject matter also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the presently disclosed subject matter into practice. The program may be in the form of source code, object code, a code intermediate source, and object code such as partially compiled form, or in any other form suitable for use in the implementation of an embodiment of the method. An embodiment relating to a computer program product comprises computer executable instructions corresponding to each of the processing steps of at least one of the methods set forth. These instructions may be subdivided into subroutines and/or be stored in one or more files that may be linked statically or dynamically. Another embodiment relating to a computer program product comprises computer executable instructions corresponding to each of the devices, units and/or parts of at least one of the systems and/or products set forth.
Figure 3a shows a computer readable medium 1000 having a writable part 1010, and a computer readable medium 1001 also having a writable part. Computer readable medium 1000 is shown in the form of an optically readable medium. Computer readable medium 1001 is shown in the form of an electronic memory, in this case a memory card. Computer readable medium 1000 and 1001 may store data 1020 wherein the data may indicate instructions, which when executed by a processor system, cause a processor system to perform an embodiment of the primary client method, secondary client method, and/or relay methods. The computer program 1020 may be embodied on the computer readable medium 1000 as physical marks or by magnetization of the computer readable medium 1000. However, any other suitable embodiment is conceivable as well. Furthermore, it will be appreciated that, although the computer readable medium 1000 is shown here as an optical disc, the computer readable medium 1000 may be any suitable computer readable medium, such as a hard disk, solid state memory, flash memory, etc., and may be non-recordable or recordable. Computer program 1020 comprises instructions for causing a processor system to perform an embodiment of said primary client method, secondary client method, and/or relay method.
Figure 3b shows in a schematic representation of a processor system 1140 according to an embodiment of a primary client device, secondary client device, and/or relay server. The processor system comprises one or more integrated circuits 1110. The architecture of the one or more integrated circuits 1110 is schematically shown in Figure 3b. Circuit 1110 comprises a processing unit 1120, e.g., a CPU, for running computer program components to execute a method according to an embodiment and/or implement its modules or units. Circuit 1110 comprises a memory 1122 for storing programming code, data, etc. Part of memory 1122 may be read-only. Circuit 1110 may comprise a communication element 1126, e.g., an antenna, connectors or both, and the like. Circuit 1110 may comprise a dedicated integrated circuit 1124 for performing part or all of the processing defined in the method. Processor 1120, memory 1122, dedicated IC 1124 and communication element 1126 may be connected to each other via an interconnect 1130, say a bus. The processor system 1110 may be arranged for contact and/or contact-less communication, using an antenna and/or connectors, respectively.
For example, in an embodiment, processor system 1140, e.g., the primary client device, secondary client device, and/or relay server may comprise a processor circuit and a memory circuit, the processor being arranged to execute software stored in the memory circuit.
For example, the processor circuit may be an Intel Core i7 processor, ARM Cortex-R8, etc. The memory circuit may be an ROM circuit, or a non-volatile memory, e.g., a flash memory. The memory circuit may be a volatile memory, e.g., an SRAM memory. In the latter case, the device may comprise a non-volatile software interface, e.g., a hard drive, a network interface, etc., arranged for providing the software.
While system 1140 is shown as including one of each described component, the various components may be duplicated in various embodiments. For example, the processing unit 1120 may include multiple microprocessors that are configured to independently execute the methods described herein or are configured to perform elements or subroutines of the methods described herein such that the multiple processors cooperate to achieve the functionality described herein. Further, where the system 1140 is implemented in a cloud computing system, the various hardware components may belong to separate physical systems. For example, processor 1120 may include a first processor in a first server and a second processor in a second server. For example, the server and relay server are suitable for implementation in a cloud system.
It should be noted that the above-mentioned embodiments illustrate rather than limit the presently disclosed subject matter, and that those skilled in the art will be able to design many alternative embodiments.
In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb ‘comprise’ and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The article ‘a’ or ‘an’ preceding an element does not exclude the presence of a plurality of such elements. Expressions such as “at least one of" when preceding a list of elements represent a selection of all or of any subset of elements from the list. For example, the expression, “at least one of A, B, and C” should be understood as including only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The presently disclosed subject matter may be implemented by hardware comprising several distinct elements, and by a suitably programmed computer. In the device claim enumerating several parts, several of these parts may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.
In the claims references in parentheses refer to reference signs in drawings exemplifying embodiments or to formulas of embodiments, thus increasing the intelligibility of the claim. These references shall not be construed as limiting the claim.
Claims (1)
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| NL2035471A NL2035471B1 (en) | 2023-07-25 | 2023-07-25 | Improved system for secure transmission of authentication data |
| PCT/EP2024/071201 WO2025021952A1 (en) | 2023-07-25 | 2024-07-25 | Improved system for secure transmission of authentication data |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| NL2035471A NL2035471B1 (en) | 2023-07-25 | 2023-07-25 | Improved system for secure transmission of authentication data |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| NL2035471B1 true NL2035471B1 (en) | 2025-02-10 |
Family
ID=88517466
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| NL2035471A NL2035471B1 (en) | 2023-07-25 | 2023-07-25 | Improved system for secure transmission of authentication data |
Country Status (2)
| Country | Link |
|---|---|
| NL (1) | NL2035471B1 (en) |
| WO (1) | WO2025021952A1 (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20130185210A1 (en) * | 2011-10-21 | 2013-07-18 | The Board of Trustees of the Leland Stanford, Junior, University | Method and System for Making Digital Payments |
| US20140282961A1 (en) * | 2013-03-15 | 2014-09-18 | Aol Inc. | Systems and methods for using imaging to authenticate online users |
| US20160373428A1 (en) | 2011-12-22 | 2016-12-22 | Paypal, Inc. | Smart phone login using qr code |
| US20170244555A1 (en) * | 2014-10-29 | 2017-08-24 | Hewlett-Packard Development Company, L.P. | Active authentication session transfer |
| US20210111889A1 (en) * | 2019-10-11 | 2021-04-15 | Atakama LLC | Relay network for encryption system |
-
2023
- 2023-07-25 NL NL2035471A patent/NL2035471B1/en active
-
2024
- 2024-07-25 WO PCT/EP2024/071201 patent/WO2025021952A1/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20130185210A1 (en) * | 2011-10-21 | 2013-07-18 | The Board of Trustees of the Leland Stanford, Junior, University | Method and System for Making Digital Payments |
| US20160373428A1 (en) | 2011-12-22 | 2016-12-22 | Paypal, Inc. | Smart phone login using qr code |
| US20140282961A1 (en) * | 2013-03-15 | 2014-09-18 | Aol Inc. | Systems and methods for using imaging to authenticate online users |
| US20170244555A1 (en) * | 2014-10-29 | 2017-08-24 | Hewlett-Packard Development Company, L.P. | Active authentication session transfer |
| US20210111889A1 (en) * | 2019-10-11 | 2021-04-15 | Atakama LLC | Relay network for encryption system |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2025021952A1 (en) | 2025-01-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20250202693A1 (en) | Systems and methods for deployment, management and use of dynamic cipher key systems | |
| US9935925B2 (en) | Method for establishing a cryptographically protected communication channel | |
| US10250573B2 (en) | Leveraging transport-layer cryptographic material | |
| US20220191016A1 (en) | Methods, apparatuses, and computer program products for frictionless electronic signature management | |
| RU2437229C2 (en) | Method and device for joint use of secret information by devices in home network | |
| KR101265873B1 (en) | Distributed Single Signing Service Method | |
| US8661254B1 (en) | Authentication of a client using a mobile device and an optical link | |
| US9166975B2 (en) | System and method for secure remote access to a service on a server computer | |
| CN106878245B (en) | Graphic code information providing and obtaining method, device and terminal | |
| CN116233832A (en) | Verification information sending method and device | |
| WO2019020051A1 (en) | METHOD AND APPARATUS FOR SECURITY AUTHENTICATION | |
| KR20200107931A (en) | System and method for key generation and storage for multi-point authentication | |
| CN101427510A (en) | Digital pass for network function description | |
| JP2023532976A (en) | Method and system for verification of user identity | |
| KR101879758B1 (en) | Method for Generating User Digital Certificate for Individual User Terminal and for Authenticating Using the Same Digital Certificate | |
| CN107409043B (en) | Distributed processing of products based on centrally encrypted storage data | |
| JP5622668B2 (en) | Application authentication system, application authentication method | |
| Büttner et al. | Protecting FIDO Extensions Against Man-in-the-Middle Attacks | |
| Wagner et al. | Remote WebAuthn: FIDO2 Authentication for Less Accessible Devices. | |
| NL2035471B1 (en) | Improved system for secure transmission of authentication data | |
| WO2015104567A1 (en) | Secure communication between a server and a client web browser | |
| CN114761958A (en) | Apparatus and method for secure communication | |
| US12212578B2 (en) | Partial payload encryption with integrity protection | |
| CN113545004A (en) | Authentication system with reduced attack surface | |
| KR102123405B1 (en) | System and method for providing security membership and login hosting service |