FIELD OF THE INVENTION

The invention relates to a signature generation system and associated devices and methods, including a signing server device, a document provider device, a user signing device, a signing server method, a document provider method, and a user signing method. The invention also relates to a computer-readable medium.

BACKGROUND OF THE INVENTION

Remote and/or server-aided signing are important tools for establishing online trust, especially for electronic transactions. For instance, digital/electronic signatures may be used to safely transfer funds or perform transactions with public services online. Underlining its importance is for example EU regulation 910/2014, also known as elDAS, or electronic IDentification, Authentication and trust Services, that sets standards for the security of digital signatures, timestamps, electronic seals, and various other primitives. The regulation mandates EU member states to recognize signatures that meet these standards.

For instance, in some scenarios for remote/server-aided signing, a user may be connected to a service provider via a browser, where he wishes to sign, say, a contract with the service provider. When the user has read and agrees the terms in the contract, using remote/server-aided signing, a signing server can be contacted to produce or help to produce, for the service provider, a digital signature of the user on the contract.

SUMMARY OF THE INVENTION

The inventors realized that there are multiple relevant problems to be addressed in signature generation systems, e.g., based on remote and/or server aided signing.

One problem when securing the process of digital signing is to ensure that the digital signature is really computed on the data that the user intends to sign. Such a problem may be particularly pressing in a white-box setting where an attacker has access to the device where the signature is created or, in a remote signing scenario, where the signature is approved by the user, e.g., a mobile device of the user. Another problem is profiling: in remote or server-aided signing scenarios, the signing server may gain a lot of profiling information, e.g., the signing server may learn which documents are signed, by whom, for which service provider, etcetera. In particular, the combination of such data may allow a signing server to obtain a rich profile of its users, which poses a problem not only from the perspective of privacy but also from the perspective of avoiding identity theft.

To better address one or more of the concerns discussed above, a signature generation system is proposed as defined by the claims. A signing server device may determine a digital signature on a document to be signed for a service provider device, possibly together with a user signing device, e.g., a mobile phone with an app. The service provider may make the document to be signed available to the user signing device. The user may confirm the document to be signed on the user signing device, and the user signing device may provide a user identifier and the confirmation to the signing server device. The signing server device may generate the digital signature based on private key material that it has stored along with the user identifier.

Interestingly, the signing server may generate the digital signature based also on a digest of the document to be signed that it obtains from a document provider device. The document provider device may have in turn obtained the digest of the document to be signed from the service provider. The signing server may also provide the generated digital signature to the document provider device that may in turn provide it to the service provider device.

Accordingly, a signature generation system is provided that reduces the amount of profiling that can be performed by various devices in the system, e.g., the system provides what is known as“privacy by design”. The document provider device may only learn that there is a user who wishes to sign a document at the service provider, e.g., without knowing any identity or even pseudonym of the user and/or the document to be signed. The signing server device may only learn that a particular user has signed a document, e.g., without knowing the document to be signed and/or the service provider device for which it was signed. Hence, neither party may be able to perform rich profiling of users, e.g., neither party may learn that a particular user, or user signing device, signed a document at a particular service provider device.

Moreover, various single points of failure may be avoided in the signature generation system with respect to the integrity of the document to be signed, e.g., it may be avoided that an attacker is able to forge a signature by attacking an individual node in the system. For instance, an attacker attacking the signature service device may generate faulty signatures but they may not correspond to the digest provided by the service provider device, and an attacker at the user signing device may be similarly unable to select the document to be signed since it may not correspond to the digest provided by the service provider device. Also, the selection of the document to be signed by the service provider and/or forwarded by the document provider device may need to be confirmed by the user of the user signing device.

In other words, the inventors realized that, when a signature and its corresponding verification information would come from one source controlled by the user, then an attacker could lure the user into entering his credentials by showing the right document to be signed, but feeding the signature server device with a different document to be signed of his choice. Since all information the signature server device would get in such a case, is originated from the user, the signature server device could not distinguish between a document to be signed that the user wishes to sign, and a maliciously formed one. The inventors realized that if a document to be signed originates in an environment outside the control of the user, e.g., at a service provider device, then this environment can provide the document to be signed to the user signing device and also ensure that the generated signature will be a signature on this document, e.g., by providing a digest of the document to be signed to the signing server device. Moreover, this can be done with a minimal amount of information being learned by the signing server device by the introduction of a document provider device that exchanging information with the service provider device and signing server device and itself also learns little information. Accordingly, various embodiments advantageously combine data minimization and security in a single system.

In some embodiments, the signing server device and the user signing device determine the digital signature on the document to be signed as a joint computation based on the private key material of the signing server device and additional private key material of the user signing device. In such embodiments, the signing server device may be unable to generate digital signatures on behalf of the user itself, e.g., the user may be ensured that its presence is required to generate a valid digital signature, further improving assurance.

Various embodiments are based on web sessions, e.g., SAML web sessions. For example, the service provider device may be configured to obtain a request to sign the document from a user device via a web session. The service provider may be configured to redirect the web session of the user device to the document provider device. The redirect may comprise the digest of the document to be signed. Similarly, the document provider device may be configured to provide the digital signature on the document to be signed to the service provider device by redirecting the web session of the user device to the service provider device, said redirect comprising said digital signature. Such measures may reduce the impact that the use of the system has on current systems and provide a convenient and secure flow of information making use of existing infrastructures, e.g., existing public key infrastructures.

In some embodiments using a web session, the document provider device is configured to encode data for obtaining the document to be signed in a barcode, e.g., QR- code, and to provide the barcode to the user device via the web session for scanning by the user signing device. This way, the user signing device may obtain the document to be signed from the service provider in a secure way and without error-prone manual entering of information by the user.

In an embodiment, the signing server device is configured to store a list of currently active signing sessions for checking if no other signing session with the user identifier is currently active. The signing server device may add the user identifier to said list after obtaining the user identifier from the user signing device and remove the user identifier from said list after determining the digital signature. This may prevent various attacks on the user signing device in which an attacker shows a document from one signing session to the user for approval but performing a signing with the signing server device on another document. For instance, in such an attack, an attacker may wait for the user to initiate a legitimate signing session, e.g., start a signing app, enter a PIN code or password; and then perform the signing with the other document.

In particular, the signing server device may be configured to provide further data for obtaining the document to be signed to the user signing device. The further data may be provided only if no other signing session with the user identifier is currently active. For example, the user signing device may need the further data to obtain the document. This may prevent an attacker at the user signing device from learning which document the user wanted to sign in order to show this document to the user for approval, while performing the signing with the signing server device on another document. For instance, the further data may comprise one or more of an encryption of the document to be signed, an encryption of a network location of the document to be signed, and a decryption key. For instance, the further data may comprise an encryption of a network location of the document to be signed, the data encoded in the barcode comprising a decryption key for said encryption. Other aspects relate to a signing server device, a document provider device, a user signing device, a signing server method, a document provider method, and a user signing method as defined by the claims.

A method according to the invention may be implemented on a computer as a computer implemented method, or in dedicated hardware, or in a combination of both.

Executable code for a method according to the invention 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 a method according to the invention when said program product is executed on a computer.

In a preferred embodiment, the computer program comprises computer program code adapted to perform all the steps of a method according to the invention when the computer program is run on a computer. Preferably, the computer program is embodied on a computer readable medium.

Another aspect of the invention provides a method of making the computer program available for downloading. This aspect is used when the computer program is uploaded into, e.g., Apple’s App Store, Google’s Play Store, or Microsoft’s Windows Store, and when the computer program is available for downloading from such a store.

BRIEF DESCRIPTION OF THE DRAWINGS

Further details, aspects, and embodiments of the invention 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,

Fig. la schematically shows an example of an embodiment of a service provider device,

Fig. lb schematically shows an example of an embodiment of a document provider device,

Fig. lc schematically shows an example of an embodiment of a signing server device,

Fig. Id schematically shows an example of an embodiment of a user signing device, Fig. le schematically shows an example of an embodiment of a user device, Fig. 2 schematically shows an example of an embodiment of a signature generation system,

Fig. 3 schematically shows an example of an embodiment of a signature generation system,

Fig. 4 schematically shows an example of an embodiment of a signature generation system,

Fig. 5 schematically shows an example of an embodiment of a signature generation system,

Fig. 6a schematically shows an example of an embodiment of a signing server method,

Fig. 6b schematically shows an example of an embodiment of a document provider method,

Fig. 6c schematically shows an example of an embodiment of a user signing method,

Fig. 7a schematically shows a computer readable medium having a writable part comprising a computer program according to an embodiment,

Fig. 7b schematically shows a representation of a processor system according to an embodiment.

List of Reference Numerals:

110 a service provider device

111 a document provider device

112 a signing server device

113 a user signing device

114 a user device

120-124 a communication interface

130-134 a processor

140-144 a memory

153-154 a user interface

163 a camera 200 a signature generation system

210 a service provider device

211 a document provider device

212 a signing server device

213 a user signing device

241 a document to be signed

242 a digest of the document to be signed

243 a digital signature

244 a user identifier

245 a list of user identifiers and associated key material

246 a confirmation

260 a computer network

300 a signature generation system

310 a service provider device

311 a document provider device

312 a signing server device

313 a user signing device

314 a user device

315 a user

341 a document to be signed

342 a digest of the document to be signed

343 a digital signature

344 a user identifier

346 a confirmation

347 a network location of the document to be signed

348 data for obtaining the document to be signed

360-372 a message

360 a selection of the document to be signed

361 a request to sign the document

362, 372 a redirect

365, 366 a barcode

400 a signature generation system 410 a servi ce provi der devi ce

411 a document provider device

412 a signing server device

413 a user signing device

414 a user device

431 an activity checking unit

447 a network location of the document to be signed

448 data for obtaining the document to be signed

449 further data for obtaining the document to be signed

450 a list of currently active signing sessions

462, 463, 465, 466, 470, 473 a message

500 a signature generation system

510 a servi ce provi der devi ce

511 a document provider device

512 a signing server device

513 a user signing device

514 a user device

515 a user

560 Open connection at service provider device

561 Send document to user device

562 Show document

563 Press sign button

564 Request Signature procedure

565 Redirect(dest: document provider device, content: Signed Token)

566 Signed Token

567 Token: name service provider, document hash, download link, signature

568 signEnrollment: document hash, encrypted download link

569 signEnrollmetReply: SessionCounter

570 QR-code: signType, decryption key for download link, signSessionCounter

571 open QR scanning mode of user signing device

572 SignSetup: appID, SignSessionCounter

573 verify appID not associated with another session

574 encrypted download link 575 decrypt encrypted download link, follow link, verify signature on document

576 show document

577 Press sign button

578 enter PIN, OTP

579 SignRequest

580 SignReply

581 Show green sign button

582 press send

583 Sign Acknowledge

584 SignResult: SignSessionCounter, signature

585 Redirect(dest: service provider device, content: signature)

586 signature

700 a signing server method

710 arranging digital communication

720 storing user identifiers and key material

730 obtaining a digest

740 obtaining a user identifier and a confirmation

750 determining a digital signature

760 providing said digital signature

800 a document provider method

810 arranging digital communication

820 obtaining a digest

830 providing said digest

840 obtaining a digital signature

850 providing said digital signature

900 a user signing method

910 obtaining a document to be signed

920 obtaining a confirmation

930 providing a user identifier and the confirmation

1000 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

DETAILED DESCRIPTION OF THE EMBODIMENTS

While this invention 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 invention and not intended to limit the invention 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 invention is not limited to the embodiments, and the invention lies in each and every novel feature or combination of features described herein or recited in mutually different dependent claims.

Fig. la schematically shows an example of an embodiment of a service provider device 110. Service provider device 110 comprises a processor 130 and a memory 140. Memory 140 may be used for data and/or instruction storage. For example, memory 140 may comprise software and/or data on which processor 130 is configured to act. Memory 140 may also store various information, e.g., one or more of a document to be signed, a digest of the document the be signed, and a digital signature on the document to be signed. Processor 130 may be implemented as one or more processor circuits, e.g. microprocessors, ASICs, FPGA and the like. Memory 140 may comprise computer program instructions which are executable by processor 130. Processor 130, possibly together with memory 140, is configured according to an embodiment of a service provider device. For example, service provider device 110 may be for use in a signature generation system according to an embodiment.

Service provider device 110 may also comprise a communication interface

120 arranged to communicate with other devices, e.g., of a signature generation system, as needed. For example, the communication interface may comprise a connector, e.g., a wired connector, e.g., an Ethernet connector, or a wireless connector, e.g., an antenna, e.g., a Wi-Fi, 4G or 5G antenna. In an embodiment, communication interface 120 is arranged for digital communication with at least a user device and/or a user signing device. In an embodiment, communication interface 120 is arranged for digital communication with at least a user signing device and a document provider device.

Service provider device 110 may be configured to make a document to be signed available to a user signing device, e.g., by sending the document or providing it on a network location; to provide a digest of a document to be signed to a document provider device, e.g., by sending it directly or by means of a redirect via a user device; and/or to obtain a digital signature on the document to be signed from the document provider device, e.g., by receiving it directly or by means of a redirect via the user device. In various embodiments, service provider device 110 is a web, e.g., HTTP and/or HTTPS, server.

Fig. lb schematically shows an example of an embodiment of a document provider device 111. Document provider device 111 comprises a processor 131 and a memory 141. Memory 141 may be used for data and/or instruction storage. For example, memory 141 may comprise software and/or data on which processor 131 is configured to act. Memory 141 may also store various information, e.g., one or more of a digest of a document the be signed, and a digital signature on the document to be signed. Processor 131 may be implemented as one or more processor circuits, e.g. microprocessors, ASICs, FPGA and the like. Memory 141 may comprise computer program instructions which are executable by processor 131. Processor 131, possibly together with memory 141, is configured according to an embodiment of a document provider device. For example, document provider device 111 may be for use in a signature generation system according to an embodiment.

Document provider device 111 may also comprise a communication interface

121 arranged to communicate with other devices, e.g., of a signature generation system, as needed. For example, the communication interface may comprise a connector, e.g., a wired connector, e.g., an Ethernet connector, or a wireless connector, e.g., an antenna, e.g., a Wi-Fi, 4G or 5G antenna. In an embodiment, communication interface 121 is arranged for digital communication with one or more of a user device, a signing server device, and a service provider device. In an embodiment, communication interface 121 is arranged for digital communication with at least a user device and a signing server device. In an embodiment, communication interface 121 is arranged for digital communication with at least a service provider device and a signing server device.

Document provider device 111 may be configured to obtain a digest of a document to be signed from the service provider device, e.g., by receiving it directly or by means of a redirect via a user device; to provide said digest to the signing server device for determining a digital signature on the document to be signed based on said digest, e.g., by sending it directly; to obtain the digital signature on the document to be signed from the signing server device, e.g., by receiving it directly; and/or to provide said digital signature to the service provider device, e.g., by sending it directly or by means of a redirect via the user device. In various embodiments, document provider device 111 is a web, e.g., HTTP and/or HTTPS, server, e.g., a server providing web services.

Fig. lc schematically shows an example of an embodiment of a signing server device 112. Signing server device 112 comprises a processor 132 and a memory 142.

Memory 142 may be used for data and/or instruction storage. For example, memory 142 may comprise software and/or data on which processor 132 is configured to act. Memory 142 may also store various information, e.g., one or more of a digest of a document to be signed, a digital signature on the document to be signed, a user identifier, a list of user identifiers and associated private key material, and a confirmation of the document to be signed. Processor 132 may be implemented as one or more processor circuits, e.g. microprocessors, ASICs, FPGA and the like. Memory 142 may comprise computer program instructions which are executable by processor 132. Processor 132, possibly together with memory 142, is configured according to an embodiment of a signing server device. For example, signing server device 112 may be for use in a signature generation system according to an

embodiment.

Signing server device 112 may also comprise a communication interface 122 arranged to communicate with other devices, e.g., of a signature generation system, as needed. For example, the communication interface may comprise a connector, e.g., a wired connector, e.g., an Ethernet connector, or a wireless connector, e.g., an antenna, e.g., a Wi-Fi, 4G or 5G antenna. In an embodiment, communication interface 122 is arranged for digital communication with a document provider device and/or a user signing device.

Signing server device 112 may be configured to obtain a digest of a document to be signed from a document provider device, e.g., by receiving it directly. For example, the document provider device may have in turn obtained the digest from a service provider device. Signing server device 112 may be further configured to obtain a user identifier of the list of user identifiers and a confirmation of the document to be signed from a user signing device, e.g. by receiving the information from the user signing device. Signing server device 112 may be further configured to determine a digital signature on the document to be signed based on the digest of the document to be signed and private key material associated to the user identifier, for example, as a joint computation with the user signing device based on its private key material and additional private key material of the user signing device. Signing server device 112 may be further configured to provide said digital signature to the document provider device, e.g., by sending it to the document provider device, e.g., for providing said digital signature to the service provider device. In various embodiments, signing server device 112 is a web, e.g., HTTP and/or HTTPS, server, e.g., a server providing web services.

Fig. Id schematically shows an example of an embodiment of a user signing device 113. User signing device 113 comprises a processor 133 and a memory 143. Memory 143 may be used for data and/or instruction storage. For example, memory 143 may comprise software and/or data on which processor 133 is configured to act. Memory 143 may also store various information, e.g., one or more of a document to be signed, a user identifier, and a confirmation of the document to be signed. Processor 133 may be implemented as one or more processor circuits, e.g. microprocessors, ASICs, FPGA and the like. Memory 143 may comprise computer program instructions which are executable by processor 133. Processor 133, possibly together with memory 143, is configured according to an embodiment of a user signing device. For example, user signing device 113 may be for use in a signature generation system according to an embodiment.

User signing device 113 may also comprise a communication interface 123 arranged to communicate with other devices, e.g., of a signature generation system, as needed. For example, the communication interface may comprise a connector, e.g., a wired connector, e.g., an Ethernet connector, or a wireless connector, e.g., an antenna, e.g., a Wi-Fi, 4G or 5G antenna. In an embodiment, communication interface 123 is arranged for digital communication with a service provider device and/or a signing server device.

User signing device 113 may further comprise a user interface 153. User interface 153 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 for showing the document to be signed to a user, e.g., via a screen of or connected to user signing device 113. The user interface may be arranged for accommodating user interaction for obtaining confirmation of the document to be signed from the user, e.g., via a confirmation button.

In some embodiments, user signing device 113 may also comprise a camera 163. Camera 163 may be arranged for obtaining an image of a barcode, e.g., shown on a user device and presented by the user, e.g., via a camera.

User signing device 113 may be configured to obtain a document to be signed made available by a service provider device, e.g., by receiving the document from a service provider device or by obtaining the document from a network location on which the service provider has made the document available. For instance, user signing device 113 may obtain the network location, e.g., download link, encoded in a barcode captured by camera 163.

User signing device 113 may be further configured to obtain a confirmation of the document to be signed from a user of the user signing device via the user interface, e.g., by clicking on a confirmation button. User signing device 113 may also be configured to provide a user identifier of the user signing device and/or the confirmation of the document to be signed to the signing server device, e.g., by sending the information to the signing server device. For example, user signing device 113 may be a portable device, e.g., a mobile phone, a tablet, a laptop, and the like. For example, at least some of the functions of user signing device 113 described herein may be provided by an app running on user signing device 113.

Fig. le schematically shows an example of an embodiment of a user device 114. User device 114 comprises a processor 134 and a memory 144. Memory 144 may be used for data and/or instruction storage. For example, memory 144 may comprise software and/or data on which processor 134 is configured to act. Memory 143 may also store various information, e.g., one or more of document to be signed and a barcode. Processor 134 may be implemented as one or more processor circuits, e.g. microprocessors, ASICs, FPGA and the like. Memory 144 may comprise computer program instructions which are executable by processor 134. Processor 134, possibly together with memory 144, is configured according to an embodiment of a user device. For example, user device 114 may be for use in a signature generation system according to an embodiment.

User device 114 may also comprise a communication interface 124 arranged to communicate with other devices, e.g., of a signature generation system, as needed. For example, the communication interface may comprise a connector, e.g., a wired connector, e.g., an Ethernet connector, or a wireless connector, e.g., an antenna, e.g., a Wi-Fi, 4G or 5G antenna. In an embodiment, communication interface 124 is arranged for digital

communication with a service provider device and/or a signing server device. User device 114 may further comprise a user interface 154. User interface 154 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 obtaining a selection of a document to be signed, e.g., via a selection button presented to the user on the user interface.

User device 114 may be configured to obtain a selection of a document to be signed from a user, e.g. via user interface 154. User device 114 may be further configured to provide a request to sign the document to a service provider, e.g., in the form of a web request of a web session. User device 114 may be further configured to provide a web session to the user, e.g., using browser software. For instance, user device 114 may obtain a redirect of the web session from the service provider to the document provider, the redirect comprising a digest of the document to be signed and/or a location of the document to be signed, and follow this redirect. User device 114 may also obtain a redirect of the web session by the document provider to the service provider, the redirect comprising a signature on the document to be signed, and follow this redirect. For instance, user device 114 may be a desktop PC, a tablet, etcetera. User device 114 may run a web browser, e.g., to provide the web session to the user.

Fig. 2 schematically shows an example of an embodiment of a signature generation system 200. Signature generation system 200 may comprise one or more of a service provider device 210, a document provider device 211, a signing server device 212, and a user signing device 213. For example, some of the devices may be based on respective devices 110-113 discussed above. Although not shown in the figure, signature generation system 200 may also comprise a user device, e.g., based on user device 114. The signature generation system 200 may be for providing a signature 243 on a document to be signed 241 to service provider 210. Typically, a device in signature generation system 200 comprises a memory, a processor, and a communication interface, as discussed above (not separately shown in this figure). Typically, user signing device 213 comprises a user interface (not shown), and so does a user device of signature generation system 200, if present.

The various devices of signature generation system 200, e.g., service provider device 210, document provider device 211, signing server device 212, and/or user signing device 213, are connected by a computer network 260. The computer network may be an internet, an intranet, a LAN, a WLAN, etc. The computer network may be the Internet. The computer network may be wholly or partly wired, and/or wholly or partly wireless. For example, the computer network may comprise Ethernet connections. For example, the computer network may comprise wireless connections, such as Wi-Fi, ZigBee, and the like. Respective devices may comprise communication interfaces, e.g., communication interfaces 120-124 in Figs la-ld, which are arranged to communicate with other devices of system 200 as needed. Computer network 260 may comprise known elements such as, e.g., a router, a hub, etc. Communication may be in the form of digital messages, e.g., sent and received in electronic form. Computer network 260 may comprise additional devices.

For the purpose of explication, Fig. 2 shows various elements that may be stored, at various stages of the operation of signature generation system 200, by the various devices of the system. For example, shown are a document to be signed 241, a digest 242 of the document to be signed, a digital signature 243 of the document to be signed, a user identifier 244, a list 245 of user identifiers and associated key material, and a confirmation 246.

Moreover, for the purpose of explication, Fig. 2 shows various communication patterns, indicated by dashed lines between devices of the system. A dashed line may between two devices may indicate that one of the devices provides information to the other device. For instance, dashed lines are shown between service provider device 210 and user signing device 213; between service provider device 210 and document provider device 211; between document provider device 211 and signing server device 212; and between signing server device 212 and user signing device 213.

A device may provide information to another device through direct communication, e.g., the device may send the information to the other device over computer network 260. In fact, in some embodiments, each piece of information provided by a device to another device is sent over computer network 260 by the respective device and received by the respective other device. Note that such direct sending and receiving may still comprise the information passing through multiple hops of the communication network, such as hubs, routers, switches, etcetera. Direct sending and receiving may use various communication protocols, e.g., using a RESTful API, using XML-encoded messages, etcetera.

However, direct sending and receiving is not necessary, e.g., in various embodiments some information provided by a first device to a second device may be provided in the form of a redirect, e.g., of a web session of a user device. For instance, the first device may redirect the web session to the second device. The redirect may comprise the information to be provided, e.g., as part of the redirect uniform resource identifier (URI) or uniform resource locator (URL), e.g., in a query component of the URI. Redirecting web sessions, e.g., URL redirection/URL forwarding, and passing information in such redirects is known per se in the art, e.g., in SAML, e.g., through the HTTP redirect binding of SAML, etcetera.

Service provider device 210 may be configured to obtain a document to be signed 241. For example, document to be signed 241 may be provided by, entered by, or selected by, a user, e.g., at service provider device 210 itself or at a user device, e.g., in a web session with service provider device 210. For instance, service provider device 210 may instantiate document to be signed 241, e.g., a contract, from a template based on information provided by the user. Obtaining document 241 may comprise presenting document 241 to the user and obtaining a request or confirmation by the user to sign the document. The document may be plain text or formatted, e.g., as HTML and/or CSS, RTF, DOC, etc. However, the document can also be, e.g., an image and/or non-textual data.

Service provider device 210 may be further configured to compute a digest 242 of the document to be signed and provide it to document provider device 211, for example, by sending it to document provider device 211 or by redirecting a user device to document provider device 211, the redirect comprising the digest. The digest may be for determining digital signature 243 based on the digest. As is known in the art, in various digital signature schemes, generating a signature on a document comprises generating a digest, e.g., a hash, of the document to be signed and determining the signature based on the digest and private key material, e.g., a private key of the signer. Generally, document to be signed 241 is not derivable from digest 242, e.g., at least signing server device 212 may not be able to derive document to be signed 241 from digest 242. This may improve protection of sensitive information in signature generation system 200 by making data theft at or by the signing server device more difficult.

For instance, the digital signature may be an RSA signature, e.g. generated according to the PKCS #1 standard. The digest may comprise at least one RSA-compatible hash, e.g., one or more of a MD2, MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256 hash. The digital signature may also be an EdDSA signature. The digest may comprise at least one EdDSA-compatible hash, e.g., a SHA-512 or SHAKE256 hash. The digital signature may also be a DSA signature. The digest may comprise at least one DSA-compatible hash, e.g., a SHA-1 or SHA-2 hash. A hash may be padded, e.g., using EMSA-PSS-ENCODE padding, e.g., as defined in RFC 8017. The digest may comprise multiple hashes, e.g., this may allow a choice of hash and/or a choice of digital signature to be made after the digest is provided. In some embodiments, service provider device 210 provides digest 242 to document provider device 211 digitally signed by the service provider device or otherwise authenticates to document provider device 211 when sending the digest, which may enable the document provider device to ensure that the service provider is trusted.

Document provider device 211 may be configured to obtain digest 242 of the document to be signed from service provider device 210, e.g., directly or via a redirect as discussed above. Document provider device 211 may be configured to accept digests 242 only from known service provider devices, e.g., by checking that the digest was sent from a known network location, that the service provider device correctly authenticated, that the digest 242 was digitally signed with a key of a known service provider device, etcetera. This may increase security of the system by ensuring that only service providers known to the document provider are able to initialize signature generation.

Document provider device 211 may be further configured to provide digest 242 to signing server device 212. If the digest 242 comprises multiple hashes, as discussed above, document provider device 211 may make a selection of a subset of the hashes and provide only the subset. Typically, document provider device 211 sends digest 242 to signing server device 212, e.g., in the form of a web service query, RESTful request, etcetera.

Document provider device 211 may digitally sign digest 242 in order to allow signing server 212 to authenticate the document provider device. For instance, traffic between document provider device 211 and signing server device 212 may be secured via TLS, e.g., using client authentication via certificates. For instance, both document provider device 211 and the signing server device 212 may have PKI certificates for use in such a secure connection.

Service provider device 210 may be further configured to make document to be signed 241 available to user signing device 213. For example, service provider device 210 may send document 241 to the user signing device. Service provider device 210 may also make the document available at a network location, e.g., via a web or file server run at service provider device 210 or at an external device. In such cases, service provider 210 may provide a network location at which the document is available to user signing device 213. In an embodiment, the network location does not comprise a user identifier of the user of user signing device 213. This way, the network location can be shared with parties without disclosing the user identifier. For instance, the network location may not contain information that can be related directly to the user, e.g., a family name or pseudonym thereof. Various detailed embodiments are provided herein. In some embodiments, making the document available comprises limiting the number of times the document may be obtained at the network location, e.g., service provider 210 may be configured to answer at most one request for obtaining the document at the network location, at most two, etcetera. This may improve the confidentiality of the document to be signed. For instance, service provider device 210 may flag and/or report requests beyond the limit. User signing device 213 may also detect unauthorized access to document to be signed 241 by learning that document was already previously requested. This may be particularly advantageous to prevent unauthorized access in various embodiments presented herein where other parties, e.g., the document provider device 211, learn the location of the document to be signed but are not supposed to retrieve the document itself.

Instead or in addition to limiting the number of accesses, service provider device 210 may also otherwise limit access, e.g., by requiring an authentication to allow access to the document to be signed 241, by password-protecting the document to be signed with a password known by or provided to user signing device 213, etcetera.

User signing device 213 may be configured to obtain document to be signed 241 that was made available by the service provider device 210, e.g., by receiving the document from the service provider device 210, by obtaining a network location and retrieving the document from the network location, etc. For example, obtaining document to be signed 241 may be initiated by a user of user signing device 213 scanning a barcode in which the location of the document to be signed or other information for obtaining the document to be signed is encoded. Various examples are provided herein. Obtaining document to be signed 241 may also be initiated, e.g., by a user entering information for contacting service provider device 210, e.g., selecting the service provider, entering the network location of the document to be signed, and the like.

User signing device 213 may be configured to obtain a confirmation 246 of the document to signed from a user of the user signing device via the user interface of the user signing device. For instance, user signing device 213 shows the document to be signed to the user on a screen, and/or the user confirms that the document should be signed, e.g., by clicking a button of the user interface, etcetera. Obtaining the confirmation may comprise authenticating the user, e.g., the user may be authenticated by the entering of a password or a PIN code, biometrically, e.g., based on an iris or fingerprint scan, etcetera.

User signing device 213 may also be configured to obtain a user identifier 244 of the user signing device, e.g., a user identifier identifying the user of the device. The user identifier may be fixed, e.g., user signing device 213 is configured as a user signing device of a single user. However, this need not be the case, e.g., the user signing device may be capable of acting on behalf of multiple users. In such cases, the user may log in to the user signing device, e.g., in combination with authenticating as discussed above. The user identifier 244 may be for allowing the signing server device 212 to retrieve private key material associated with the user, e.g., the identifier is known to signing server device 212, e.g., the user may have enrolled to the signing server device 212 using user identifier 244 in an enrollment phase prior to the current signature generation. Any sort of user identifier may be used, e.g., a number, an e-mail address, etcetera.

User signing device 213 may be configured to provide user identifier 244 and/or confirmation 246 to signing server device 212. Providing user identifier 244 may comprise authenticating to signing server device 212, for instance, confirmation 246 may be provided digitally signed by the user signing device, a challenge/response authentication protocol may be used, etc. However, in various embodiments, authentication of the user signing device may be considered implicit, e.g., through participation in a joint signature computation according to various embodiments described herein. User signing device 213 may send the message to signing server device 212, e.g., through a web service, RESTful API, etc.

Signing server device 212 may be configured to obtain digest 242 of the document to be signed from document provider device 211, e.g., by receiving the digest sent by document provider device 211. Signing server device 212 may be configured to accept digests only from a given set of document provider devices 211. For example, signing server device 212 may be configured with a list of accepted document provider devices, e.g., with respective public keys and/or network addresses. Signing server device 212 may check that an incoming digest 242 was provided by an accepted document provider device, e.g., by verifying a digital signature on digest 242 or on another message and/or checking that the request came from an accepted network address. This may further improve security of the system by ensuring that a trusted document provider device is involved in the signature generation.

Signing server device 212 may also be configured to obtain user identifier 244 from user signing device 213, e.g., to receive the user identifier from device 213. Receiving the user identifier may comprise authenticating the user, e.g., verifying a digital signature, performing a challenge/response protocol, etcetera. Authentication may be implicit, as discussed above. Signing server device 212 may be configured to store a list 245 of user identifiers and associated private key material, e.g., in a memory such as memory 142. Signing server device 212 may have obtained the user identifier 244 and associated private key material in a previous enrollment phase. Signing server device 212 may retrieve the private key material associated with user identifier 244 from list 245. The private key material associated with user identifier 244 may comprise a private key of a digital signature scheme, e.g., an RSA private key, a DSA private key, an EdDSA private key, etcetera. In various embodiments in which digital signature 243 is computed as a joint computation, the private key material may be a share of a private key, as discussed in more detail later.

Signing server device 212 may be configured to determine digital signature 243 on document to be signed 241 based on digest 242 of the document to be signed and the private key material associated with user identifier 244, e.g., retrieved from list 245. For example, the private key material may comprise a secret key of a digital signature algorithm, determining digital signature 243 comprising computing the digital signature from digest 242. Various digital signature schemes in which generating a signature on a document comprises generating a digest 242 and determining the signature therefrom may be used, e.g., RSA, EdDSA, DSA, etc. As discussed, digest 242 may comprise multiple hashes, in which case signing server device 212 may be configured to select a digital signature algorithm for which a compatible hash is comprised in digest 242. As discussed in more detail later, determining digital signature 243 may also be a joint computation with user signing device 213.

Signing server device 212 may be further configured to provide digital signature 243 to document provider device 211, e.g., by sending digital signature 243 to document provider device 211, e.g., as a response to a previous query of the document provider device. Document provider device 211 may be configured to obtain digital signature 243 on document to be signed 241 from signing server device 212, e.g., by receiving the digital signature. Document provider device 211 may be further configured to provide digital signature 243 to service provider device 210, e.g., by sending it directly or by means of a redirect of a web session of a user device in which the redirect comprises the digital signature. Service provider device 210 may be configured to obtain digital signature 243 on document to be signed 241 from document provider device 211, e.g., directly or as part of a redirect of a web session of the user device.

Accordingly, in signature generation system 200, service provider 210 may to obtain digital signature 243 with various data minimization improvements. For example, signing server device 212 may obtain digest 242 of document to be signed 241 but not the document itself, so that the document may remain confidential with respect to the signing server device. Moreover, signing server device 212 may not obtain information directly from service provider device 210, e.g., digest 242 is instead obtained from document provider device 211. Hence, signing server device 212 may not need to know an identity of the service provider device 210, e.g. signing server device 212 may not be able to profile users based on what kind of service providers they use. Similarly, service provider device 210 may not need to know an identity of signing server device 212. Document provider device 211 may communicate with service provider device 210 but may not learn an identifier of the user of user signing device 213, e.g., document provider device 211 may not exchange information with the user signing device and/or user device, and hence, also document provider device 211 may not be able to profile users based on services they have used.

Interestingly, signature generation system 200 may also enable signature generation with various security advantages. For example, the signing server device may only generate a signature for a user after obtaining the user identifier from a user signing device of the user, e.g., the user signing device needs to be involved in the signature generation process. Moreover, also a service provider device and a document provider device of system 200 may need to be involved for a signature to be generated. Furthermore, by distributing information among various parties, the attractiveness of individual parties as a target for attacks may be decreased, complicating the task for an attacker to break into the system.

Surprisingly, in various embodiments of signature generation system 200, signing server device 212 does not determine digital signature 243 by itself but instead determines digital signature 243 on document to be signed 241 as a joint computation with user signing device 213. For example, the joint computation may be based on the private key material of signing server device 212 and additional private key material of user signing device 213. The joint computation may comprise computing digital signature 243 in such a way that signing server device 212 does not learn the additional private key material of the user signing device and user signing device 213 does not learn the private key material of the signing server device. When using a joint computation, the confirmation of the document to be signed that is provided by the user signing device to the signing server device may be implicit, e.g., the user signing device is configured to only take place in the joint computation if the user has provided a confirmation of the document to be signed.

Various ways of performing the joint computation are possible. For example, the key material and the private key material may comprise a secret-sharing of a secret key with which digital signature 243 is to be signed. In some embodiments, user signing device 213 may compute a partial signature of the document to be signed using its additional private key material and send it to server signing device 212. Server signing device 212 may compute digital signature 243 based on the partial signature, the digest, and its private key material. Several examples of two-party signature algorithms based on different

cryptographic primitives are given in Mihir Bellare and Ravi Sandhu: The Security of Practical Two-Party RS A Signature Schemes. Cryptology ePrint Archive, report 2001/060 (incorporated herein by reference), and Philip MacKenzie and Michael K. Reiter: Two-Party Generation ofDSA Signatures (Extended Abstract) . Bell Labs, Lucent Technologies, Murray Hill, NJ, USA (incorporated herein by reference). The first gives both multiplicative and additive ways to split an RSA key into multiple shares. For example, according to one option disclosed in the first reference, an RSA decryption exponent d may be split as d _c d _s = d mod f(N). User signing device 213 may send partial signature x _c = H(M) ^dc mod N to signing server device 212. Signing server device 212 may compute digital signature 243 based on the partial signature as x = x _c ^ds mod N.

In an embodiment, the joint computation comprises a multi-party computation (MPC), signing server device 212 providing its private key material as a private input to the MPC and user signing device 213 providing its additional private key material as a private input to the MPC. For example, the private key material and additional private key material may be combinable into a private key of the user, e.g., they are secret shares, one is an encryption and the other is a decryption key for the encryption, etcetera. Digest 242 may, e.g., be a public input to the multi-party computation, e.g., a constant, of a private input of either or both of the parties. The MPC may compute digital signature 243 based on the digest and the private key combined from the private key material and additional private key material. In some embodiments, document to be signed 241 is also a private input of user signing device 213, e.g., the digital signature scheme may not be based on the digest but the digest may instead be used by the signing server device 212 to ensure that the correct document to be signed 241 was input.

Using joint computations may further improve security of the system since signature signing device 212 by itself may not be able to generate signatures for the user. Thereby, there may be less impact of key material being stolen from signature signing device 212 and/or signature signing device 212 being induced to generate a rogue digital signature 243 that was not requested by the user. In particular, in combination with the various data minimization advantages described above, a system may be obtained in which a high degree of control is provided to a user in terms of preventing the data of the user being used in ways that are not authorized by the user. Fig. 3 schematically shows an example of an embodiment of a signature generation system 300. Signature generation system 300 may be based on signature generation system 200. Signature generation system 300 may comprise a service provider device 310, e.g., based on service provider device 110 or 210. Signature generation system 300 may comprise a document provider device 311, e.g., based on document provider device 111 or 211. Signature generation system 300 may comprise a signing server device 312, e.g., based on signing server device 112 or 212. Signature generation system 300 may comprise a user signing device 313, e.g., based on user signing device 113 or 213.

Signature generation system 300 may also comprise a user device 314, e.g., based on user signing device 114 or a user signing device of signature generation system 200. A user 315 of signature generation system 300 may interact with user device 314, e.g., using a user interface of user device 314, and/or with user signing device 313, e.g., using a user interface of user signing device 313. Preferably, user device 314 is different from user signing device 313. This may have the advantage of improving security since it is typically harder for an attacker to gain access to two devices than to one. However, user device 314 and user signing device 313 may also be combined in a single device. In this case, the security advantage may also at least in part be achieved, e.g., by shielding at least the execution of the functions of the user signing device from the execution of the functions of the user device, e.g., by means of separate execution environments, sandboxes, white-box software protection, and the like.

Typically, the various devices each comprise a memory, a processor, and a communication interface, as discussed above (not separately shown in this figure). Typically, user signing device 313 and user device 314 also comprise comprises respective user interfaces (not shown). Typically, both user interfaces are for interacting with the same user 315.

As demonstrated by the example flow diagram of Fig. 3, various embodiments of signature generation system 300 may involve a web session, or web interaction, of user 315 at user device 314. For example, user device 314 may be configured to run a web browser application that user 315 interacts with. The web session may comprise multiple web pages being served to user device 314 by at least service provider 310 and document provider device 311, e.g., linked to each other via redirects, hyperlinks, scripts, and the like. For example, the web session may comprise messages of Fig. 3 with dashed lines, e.g., the web session may comprise messages 361, 362, 366, and/or 372. For example, the web session may comprise a request 361, from user device 314 to service provider device 310, to sign document to be signed 342. This message may initiate the document signing procedure. The web session may further comprise a redirect 362 by which service provider device 310 redirects the web session of user device 314 to document provider device 311. For example, the user or service provider may select a particular document provider device to redirect to. The redirect may comprise digest 342 of the document to be signed and/or other information, e.g., as part of the query part of a uniform resource identifier. Upon receipt of digest 342, a digital signature 343 on the document to be signed may be determined and obtained by document provider device 311, as discussed with respect to signature generation system 200. The web session may further comprise a redirect 372 of the web session by document provider 311 to service provider device 310. Redirect 372 may comprise digital signature 343.

Hence, service provider device 310 may obtain digital signature 343 by redirecting 362 user device 314 to document provider device 311 and by the user device 314 being redirected back 372 by the document provider device. This may have the advantage that, from the point of view of service provider device 310, the interaction to obtain digital signature 343 may be very similar, or even identical, to existing authentication flows, e.g., based on SAML, e.g., the SAML Authentication Request Protocol. Hence, little, or in some cases even no, modification to service provider device 310 may be needed. For example, signature generation system 300 in some embodiments may be compatible with existing service provider devices 310. Similarly, for user device 314, the interaction is very similar to existing authentication flows, so that also user device 314 may require little or no

modification, and/or user 315 is able to perform the signature generation task more efficiently.

In some embodiments, the web session is further employed to provide data 348 for obtaining the document to be signed to user signing device 313. Document provider device 311 may provide such data 348 to user device 314 via the web session, e.g., in message 365, to let user signing device 313 obtain data 348. For example, document provider device 311 may encode data 348 in a barcode for scanning by user signing device 313. User device 314 may obtain message 365, e.g., a HTTP or HTTPS response, and display the web page comprised in message 365 including the barcode. User 315 may use user signing device 313 to obtain data 348, e.g., by scanning the barcode, as shown in the figure by message 366 comprising data 348. For example, user signing device 313 may scan the barcode and decode it to obtain data 348. In an embodiment, the barcode is a QR code. However, various other types of barcodes, e.g., one-dimensional/linear barcodes such as EAN2 or the Japan Post barcode, two-dimensional/matrix barcodes such as CrontoSign or JAB-Code, or circular barcodes such as ShotCode, may also be used. In general, a barcode may be any optical, machine-readable representation of data.

Data 348 for obtaining the document to be signed may take on various forms. For example, the data may comprise the document to be signed 342 itself, e.g., encrypted for decryption by the user signing device. The data may also comprise a network location, e.g., download link, of the document to be signed. For instance, the document provider may have obtained the network location 347 of the document to be signed as part of redirect 362. As discussed later, data 348 may be combinable by user signing device 313 with further data for obtaining the document to be signed, e.g., data 348 may comprise a decryption key of an encryption comprised in the further data, data 348 may comprise an encryption of which a decryption key is comprised in the further data, etcetera. Various examples are provided herein.

Providing data 348 as part of the web session as described above, e.g., using barcodes, may have as an advantage that the information used by user signing device 313 to obtain the document to be signed reaches device 313 in an efficient and secure way. For example, signing on the user signing device 313 may be initiated by message 366, e.g., by scanning the barcode, so the user does not need to type in a URI, code, etcetera, which may be difficult and error-prone. In some embodiments, security may be further improved by encoding data 348 digitally signed in the barcode.

As discussed, user device 314, e.g., running a browser, is preferably not the same device as user signing device 313. By downloading the document to be signed and presenting it to the user, user signing device 313 may help to ensure that a digital signature is produced for the document that the user intended to be signed. User 315 may verify that the document shown at user signing device 313 and the document shown at user device 314 match. Generally, an attacker trying to fool a user by showing a different document than which is registered at server signing device 312, may for instance attempt to break into (i) user signing device 313 and user device 314, or (ii) signing server device 312 and user signing device 313. Separating user device 313 and user signing device 314 may particularly help to mitigate this second type of attack.

In some embodiments, after the generation of digital signature 243, the user of user signing device 313 provides an acknowledgement of the verified signature and thereby gives the signing server device 312 permission to forward the signature to service provider 310. This may provide additional assurance that the user has given permission to forward the signature and/or that a signature is generated on the actual document that the user wanted to sign.

By way of example, Fig. 3 shows in a flow diagram various messages 360-372 that may be exchanged in document signing system 300. For example, the messages may be used to perform the various exchanges of information as discussed with respect to document signing system 200. An example flow according to the figure is now discussed, with the understanding that many variations are possible, e.g., multiple messages may be combined in a single message, additional messages may be sent, and/or the order of the messages may be varied.

User signing device 314 may be configured to obtain a selection of the document to be signed by means of a message 360, e.g., a user interaction of user 313.

Service provider device 310 may be configured to obtain document to be signed 341 by receiving message 361, e.g., message 361 may be a result of user 360 confirming that a document shown earlier in the web session should be signed, or message 361 may comprise document 341 itself.

Service provider device 310 may be configured to make document to be signed 341 available to user signing device 313, e.g., by making the document available at a network location 347 and providing location 347 of the document to be signed to document provider device 311 in redirect 362 for letting the document provider device provide the document to the user signing device.

Service provider device 310 may be configured to provide digest 342 of the document to be signed to the document provider device 311 in redirect 362 of the web session of user device 314.

Document provider device 311 may be configured to obtain digest 342 of the document to be signed in redirect 362 and to provide digest 342 to signing server device 312 in message 363. Signing server device may thus obtain digest 342 by message 363 and, e.g., may confirm message 363 with a reply 364.

Making the document to be signed available to the user signing device 313 may further comprise document provider device 311 encoding data 348 for obtaining the document to be signed in a barcode, and to provide the barcode to the user device via message 365 of the web session of user device 314. The barcode may be presented, as message 366, for scanning by user signing device 313. User signing device 313 may obtain the document to be signed, made available by the service provider device, e.g., by obtaining data 348 for obtaining the document to be signed, determining a network location of the document to be signed based at least in part on data 348, requesting 367 document to be signed 341 from service provider device 310 and obtaining the document to be signed 341 as part of a response 368 to the request.

User signing device 313 may obtain 369 confirmation 346 of the document to be signed from user 315 via the user interface of the user signing device, e.g., by showing the document and having the user press a“Sign” button”.

User signing device 313 may provide a user identifier 344 of the user signing device and confirmation 346 of the document to be signed to signing server device 312 as message 370. Signing server device 312 may thus obtain user identifier 344, that may be a user identifier of a list of user identifiers and associated private key material that it stores, and confirmation 346.

User signing device 313 may determine digital signature 343 on the document to be signed based on digest 342 and the private key material associated with user identifier 344. For example, the private key material may be the user’s private key, in which case user signing device 313 may compute the digital signature itself, or user signing device may determine digital signature 343 as a joint computation with the user signing device 313 (messages not separately shown in this figure). User signing device 313 may provide digital signature 343 to document provider device in message 371.

Document provider device 311 may obtain digital signature 343 on the document to be signed from signing server 312 in message 371. Document provider device 311 may provide digital signature 343 to service provider device 310 as part of redirect 343. Redirect 372 may be, e.g., a response to an earlier request of user device 314 (not separately shown), or redirect 372 may be pushed to user device 314 using a Comet-type interaction, e.g., a two-way web, HTTP streaming or HTTP server push interaction. Redirect 372 may also be initiated by the user, e.g., by a refresh by user device 314, by user 315 clicking a button on a web page presented by the document provider device, e.g., in message 355, etcetera. Service provider device 310 may thus obtain digital signature 343 by redirect 372.

Fig. 4 schematically shows an example of an embodiment of a signature generation system 400. Signature generation system 400 may be based on signature generation system 200 or signature generation system 300. Signature generation system 400 may comprise a service provider device 410, a document provider device 411, a signing server device 412, a user signing device 413, and/or a user device 414. For example, the devices may be based on respective devices of signature generation system 200 or 300. Fig. 4 shows a user device 414, e.g., information from service provider device 410 to document provider device 411 and/or from document provider device 411 to user signing device 412 passes through user device 414, but this is not necessary, e.g., the information can also be sent directly from one device to the other.

In various embodiments now discussed with respect to signature generation system 400, signing server device 412 is configured to store a list 450 of currently active signing sessions. List 450 may allow signing an activity checking unit 431 of server device 412 to check if no other signing session with the user identifier 444 of the user of user signing device 413 is currently active. For instance, activity checking unit 431 may add user identifier 444 to list 450 after obtaining the user identifier from user signing device 413 in a message 470, e.g., message 370 of Fig. 3. Activity checking unit 431 may remove user identifier 444 from list 450 after determining the digital signature, e.g., after sending the digital signature to document provider device 411 (not shown in this figure). Checking if no other signing session with the user identifier is active may allow to detect various security problems. For example, it may allow to detect attacks on user signing device 413 where an attacker shows an actual document to be signed on the screen but performs the signing of another document. In such an attack, an attacker may for instance wait for the user to initiate signing at the user signing device, e.g., start an app, enter a password or PIN code, etcetera; start a signing session for the other document; and then perform a signing of the other document. Such attacks may rely on opening two sessions with signing server device 412: one for the actual document and one for the other document. This may be detected by activity checking unit 431 from list 450. User identifier 444 may be also removed from the list of currently active signing sessions after a time-out, and the like.

As a response to detecting that another signing session with user identifier 444 is currently active, signing server device 412 may, for example, signal an error condition to a system administrator, notify the user, e.g., via e-mail, etcetera.

In some embodiments, obtaining user identifier 444 may comprise a user verification. For instance, a PIN-based verification may be used, e.g., based on a PIN known by the signing server device 412. For instance, the verification may be based on a

cryptographic function being computed by user signing device 413 based on one or more of a PIN, a session counter, and a challenge provided by signing server device 412. For example, use of session counters may help to detect replay attacks. In an embodiment, the cryptographic function comprises a HMAC, which may have as an advantage the result of the cryptographic function information may be sent without revealing information that can be abused to impersonate a user, e.g., it may be infeasible for an eavesdropper to create a valid HMAC on a non-observed message without knowing the HMAC key.

Interestingly, user signing device 413 may obtain the document to be signed at least in part based on further data 449 for obtaining the document to be signed provided by signing server device, e.g., in a message 473. User signing device 413 may be configured to only provide further data 449 only if no other signing session with the user identifier is currently active, e.g., based on list 450. User signing device 413 may not be able to obtain the document to be signed without further data 449. This may complicate attacks at user signing device 313 where an attacker presents the actual document the user wants to sign to the user, but determines a digital signature on another document, since the attacker needs further data 449 to obtain the actual document to be signed to show it to the user. This may imply that a signing session with the actual document exists and the signing server device 412 may thus refuse to sign the other document.

There are many possibilities for further data 449. Further data 449 can for instance be the document to be signed or a network location of the document to be signed. In preferred embodiments however, further data 449 is such that signing server device 412 cannot determine the document to be signed from further data 449, improving data protection/privacy of the user with respect to the signing server device. For instance, further data 449 may comprise one or more of an encryption of the document to be signed, an encryption of a network location of the document to be signed, and a decryption key, for instance, of an encryption of the document or the network location. This may help to ensure that the signing server device 412 does not obtain profiling information, e.g., using such further data 449 instead of a non-encrypted network location may avoid revealing an identity of the service provider that could be used for profiling.

In some embodiments, user signing device 413 combines further data 449 with data 448 from document provider device 411 for obtaining the document to be signed, for instance, data 348 discussed with respect to Fig. 3. For example, user signing device 413 may obtain data 448 by means of a barcode provided by document provider device 411 to user device 414 in message 465 for scanning 466 by user signing device 413, e.g., messages 465, 466 may correspond to messages 365, 366 discussed with respect to Fig. 3. User signing device 413 may also receive the data directly from document provider device 411. For example, in an embodiment, further data 449 comprises an encryption of a network location of the document to be signed and data 348 comprises a decryption key for decrypting this encryption. In an embodiment, data 348 comprises an encryption of a network location of the document to be signed and data 349 comprises a decryption key for decrypting this encryption. Document provider 411 may determine data 348 and further data 349 based on network location 447 of the document to be signed. For instance, document provider 411 may obtain network location 447 from service provider device 410, e.g., by means of a redirect 462 via user device 414, e.g., redirect 362 discussed with respect to Fig.

3.

User signing device 413 may also combine further data 449 with other data in order to obtain the document to be signed, e.g., data received directly from service provider device 410.

Hence, in various embodiments described above, it may be achieved that user signing device 413 needs information from signing server device 412 to obtain the document to be signed, which may prevent attacks at the user signing device as discussed above. Also, signing server device 412 may not learn the document to be signed. Even document provider device 411 may not learn the document to be signed, e.g., it may learn its location 447 but may not be able to retrieve the document, e.g., the document is served only once as described above. Hence, in various embodiments, confidentiality of the document to be signed is improved and/or assurance that the correct document is signed is increased.

Fig. 5 schematically shows an example of an embodiment of a signature generation system 500. Signature generation system 500 may be based on signature generation system 200, 300, or 400. Signature generation system 500 may comprise a service provider device 510, a document provider device 511, a signing server device 512, a user signing device 513, and/or a user device 514. For example, the devices may be based on respective devices of signature generation system 200, 300, or 400.

Phase 1. Register a signing session.

User U, 515 may have a session with servicer provider device 510 (SP). The SP may show a document to be signed requesting a signature of the user. User 515 may request/agree to sign the document.

Service provider device 510 may make the document to be signed available to user signing device 513 and provide a digest of the document to be signed to document provider device 511, e.g., by providing the download link in redirected message 565,566. Document provider device 511 may obtain the digest and provide it to signing server device 512, e.g., in message 568. Signing server device 512 may obtain the digest from message 568.

Phase 1 may use, for instance, some of the following steps/messages of Fig. 5:

560 Open connection at service provider device 510

561 Send document to be signed to user device 514

562 Show document

563 Press sign button

564 Request Signature procedure

565 Redirect(dest: document provider device, content: Signed Token)

566 Signed Token

567 Token: name service provider, document hash, download link, signature

568 signEnrollment: document hash, encrypted download link

569 signEnrollmentReply: SessionCounter

570 QR-code: signType, decryption key for download link, signSessionCounter, e.g., SessionToken (ST)

Highlighted steps of this phase:

(563) User i/, 515 may press the sign button sign.

(565) SP may reply with a redirection, e.g., using SAML, for instance, comprising:

- target: document provider device

- Signed Token:

* Service Provider ID

* Network location of the document to be signed, e.g., document download URL. The URL may be anonymized to ensure that document provider device 511 cannot link the SP 510 with U , 515.

* document digest, e.g., hash H (M)

* signature

(567) Document provider device 511 may verify the signature on the token. Document provider device 511 may pick a random encryption, e.g., AES, key K and encrypt the download link.

(568) Document provider device 511 may request a signature session at the signing server device 512, also known as backend, via a SignEnrollment message.

- Contents may comprise:

* document hash (//(M)) * Encrypted Download Link (EDL)

The backend may generate a random Session Token (ST), and store ST with H(M ) and EDL

(569) The backend may reply with SignEnrollmentReply message Contents may comprise:

* ST

(570) The document provider device, 511 may send to the browser of user device 514 a QR-code, e.g., a signed QR-code to be scanned with the app.

QR-code content may comprise:

* K

* ST

Phase 2. Document Download, Verification and Signing at User Signing Device

User 515 may have initiated a signing session on user device 514. The document provider may have enrolled a signing session and may presents a barcode, e.g., QR-code, to be scanned by the user 515 with user device 514.

User signing device 513 may obtain the document to be signed made available by the service provider device by obtaining further data for obtaining the document to be signed, e.g., an encrypted download link, in message 574; decrypting the download link using a decryption key, e.g., data for obtaining the document to be signed, scanned and decoded from the QR code of messages 570; and following the link in step 575. User signing device 513 may obtain the confirmation of the document to be signed from a user of the user signing device via the user interface in messages 577, 578, 582 and provide the user identifier, e.g., appID, of the user signing device and the confirmation of the document to be signed to the signing server device 512 in messages 579, 583. Signing server device 512 may obtain the user identifier, comprised in a stored list of user identifiers and associated private key material, and a confirmation of the document to be signed from the user signing device in messages 579, 583. Signing server device 512 may store a list of currently active signing sessions for checking if no other signing session with the user identifier, e.g., appID, is currently active. The signing server device may add the user identifier to the list. The signing server device 512 may provide further data for obtaining the document to be signed, e.g., the encrypted download link, to user signing device 513 only if no other signing session with the user identifier is currently active.

Phase 2 may use, for instance, some of the following steps/messages of Fig. 5: 571 open QR scanning mode of user signing device 572 SignSetup: appID, SignSessionCounter, e.g., SessionToken (ST)

573 verify appID not associated with another session

574 encrypted download link

575 decrypt encrypted download link, follow link, verify signature on document

576 show document

577 Press sign button

578 enter PIN, OTP

579 SignRequest

580 SignReply

581 Show green send button Send

Highlighted steps of this phase:

(571) User U , 515 may open a QR scanning mode of user signing device 513; user U may scan the barcode, e.g., QR-code, shown at user device 514. User signing device 513 may recognize the QR-code and extract the contents, e.g., decryption key K and/or ST

(572) User signing device 513 may connect to the backend with a SignSetup message.

Contents may comprise:

* user identifier, e.g., appID

* ST

(573) Signing server device 512 may verify existence of appID and verify that no signing session is already opened for this appID. The signing server device may open a signing session for appID, link H (M) corresponding ST to appld, and generate a random PSS-salt.

(574) The signing server device may reply with a SignSetupReply containing the EDL corresponding to ST.

Contents may comprise:

* Encrypted Download Link (EDL)

* PSS-salt

(575) User signing device 513 may decrypt EDL using K and download the document by following this link

(576) User signing device 513 may show the document to be signed to the user

(577) User U, 515 may verify the document and presses a sign button.

(578) User signing device 513 may authenticate user 515, e.g., by requesting a PIN and/or one-time password and computing a one-time token OTT Sign. For example, UC may be computed from a PIN entered by the user and/or a secret key stored at user signing device 513. UC may be stored during an enrollment phase enrollment at signing server device 512. For example, the one-time-token may be computed as OTT _sign = HMAC(key = UC, message = partialSignature\ \SessionCounter), where, e.g.,

UC = HASH(secretkey\ \PIN) based on a hash-based message authentication code HMAC and a hash function, e.g., cryptographic hash, HASH.

Here UC is computed from PIN entered by user and secretkey stored on User signing Device and UC is stored during User enrollment at Signing Server Device

(579) User signing device 513 may send a SignRequest Message to signing server device 512

Contents may comprise:

* appld

* SessionCounter

* partial signature of joint signature computation

* OTT Sign.

Signing server device 512 may verify one or more of:

- existence of appld,

- existence of an open signing session for appld,

- replay of sessionCounter

- correctness of PIN via OTT Sign.

Signing server device 512 may complete the signature and verify it, e.g., using H (M) and PSS-salt that is stored in the signing session for appld and the public key corresponding to appld.

Signing server device 512 may store the signature in the signing session corresponding to appld and mark the signing session as completed.

(580) Signing server device 512 may reply with SignReply.

Contents may comprise:

* digital signature on document to be signed

User signing device 513 may verify the signature on input M.

(581) User signing device 513 may show a send button to the user.

Phase 3. Sending signature to SP

User 515 may have successfully entered his credentials and/or the document shown at device 513 may have been successfully signed with his private key. User 515 may need to acknowledge success before signing server device 512 sends the signature to document provider device 511.

Signing server device 512 may determine the digital signature on the document to be signed based on the digest of the document to be signed and the private key material associated with the user identifier. Signing server device 512 may provide the digital signature to the document provider device in message 584. Signing server device 512 may remove the user identifier from the list of currently active signing sessions after determining the digital signature. Document provider device 511 may obtain the digital signature on the document to be signed from the signing server device in message 584 and provide said digital signature to the service provider device in redirected message 585,586. Service provider device 510 may obtain the digital signature from the document provider device 511 in message 585,586 redirected via user device 514.

Signing server device 512 and user signing device 514 may determine the digital signature on the document to be signed as a joint computation based on the private key material of the signing server device and additional private key material of the user signing device, messages 579 and 580 being part of the joint computation.

Phase 3 may use, for instance, some of the following steps/messages of Fig. 5:

582 press send button

583 Sign Acknowledge

584 SignResult: SignSessionCounter, e.g., SessionToken (ST); signature

585 Redirect(dest: service provider device, content: signature)

586 signature

Highlighted steps of this phase:

(582) User 515 may press a send button.

(584) User signing device 513 may send the SignAcknowledge message. Contents may comprise:

* appID

* OK

Signing server device 512 may verify whether a signing session is marked “completed” corresponding to appID.

(584) Signing server device 512 may send the SignResult message to document provider device 511.

Contents may comprise:

* ST * signature

(585) Document provider device 511 may send a redirection link, e.g., using SAML, to user device 514.

- target: service provider device 510 (SP)

- Reply Content:

* signature

(586) User device 514 may follow the redirect and contact service provider device 510.

Document provider device 511 may send an acknowledgement to the signing server device 512 and wipe all data with respect to ST.

Signing server device 512 may reply with acknowledgement to user signing device 513. Signing server device 512 may wipe all data with respect to ST. User signing device 513 may wipes all data with respect to the signing session and the close session.

In the various embodiments of the devices of Fig. 2-Fig. 5, the communication interface may be selected from various alternatives. For example, a communication interface 120-124 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, a keyboard, an application interface (API), etc.

Memories 140-144 of the devices of Fig. 2-Fig. 5 may be implemented as an electronic memory, say a flash memory, or magnetic memory, say hard disk or the like. A memory 140-144 may comprise multiple discrete memories together making up the memory. A memory 140-144 may also be a temporary memory, say a RAM. In the case of a temporary memory, the memory contains some means to obtain data before use, say by obtaining them over an optional network connection (not shown). The various memories may be storages.

Typically, the devices 110-114, 210-213, 310-314, 410-414, 510-514, each comprise a microprocessor (not separately shown) which executes appropriate software stored at the respective devices; for example, that software may have been downloaded and/or stored in a corresponding memory, e.g., a volatile memory such as RAM or a non volatile memory such as Flash (not separately shown). Alternatively, at least some of the devices may, in whole or in part, be implemented in programmable logic, e.g., as field- programmable gate array (FPGA). Some of the devices may be implemented, in whole or in part, as a so-called application-specific integrated circuit (ASIC), i.e. 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 an embodiment, the service provider comprises a document providing circuit configured to make a document to be signed available to the user signing device; a digest circuit configured to provide a digest of the document to be signed to the document provider device; and/or a signature obtaining circuit configured to obtain a digital signature on the document to be signed from the document provider device. In an embodiment, the document provider device comprises a digest circuit configured to obtain the digest of the document to be signed from the service provider device and provide said digest to the signing server device and/or a signature circuit configured to obtain the digital signature on the document to be signed from the signing server device and provide said digital signature to the service provider device. In an embodiment, the signing server device comprises a digest circuit configured to obtain the digest of the document to be signed from the document provider device; a user communication circuit configured to obtain a user identifier of the list of user identifiers and a confirmation of the document to be signed from the user signing device; a signing circuit configured to determine the digital signature on the document to be signed based on the digest of the document to be signed and the private key material associated with the user identifier; and/or a providing circuit configured to provide said digital signature to the document provider device. In an embodiment, the user signing device comprises a document obtaining circuit configured to obtain the document to be signed, made available by the service provider device; a confirmation circuit configured to obtain the confirmation of the document to be signed from a user of the user signing device via the user interface; and/or a providing circuit configured to provide the user identifier of the user signing device and the confirmation of the document to be signed to the signing server device. The devices may comprise additional circuits, e.g., the user signing device and the signing server device may each comprise respective joint computation circuits configured to determine the digital signature as a joint computation. The circuits may also be configured for additional tasks. The circuits may be a processor circuit and storage circuit, the processor circuit executing instructions represented electronically in the storage circuits.

A processor circuit may be implemented in a distributed fashion, e.g., as multiple sub-processor circuits. A storage may be distributed over multiple distributed sub storages. Part or all of the memory may be an electronic memory, magnetic memory, etc. For example, the storage may have volatile and a non-volatile part. Part of the storage may be read-only. The circuits may also be, FPGA, ASIC or the like. Fig. 6a schematically shows an example of an embodiment of a signing server method 700. Signing server method 700 may be for use in a signature generation system according to an embodiment, e.g., signature generation system 200, 300, 400, or 500. Signing server method 700 may comprise:

arranging 710 digital communication with one or more of a service provider device, a document provider device, and a user signing device;

storing 720 a list of user identifiers and associated private key material; and obtaining 730 a digest of a document to be signed from the document provider device, said document provider device having obtained the digest from a service provider device;

obtaining 740 a user identifier of the list of user identifiers and a confirmation of the document to be signed from the user signing device;

determining 750 a digital signature on the document to be signed based on the digest of the document to be signed and private key material associated to the user identifier; and/or

providing 760 said digital signature to the document provider device for providing said digital signature to the service provider device.

Fig. 6b schematically shows an example of an embodiment of a document provider method 800. Document provider method 800 may be for use in a signature generation system according to an embodiment, e.g., signature generation system 200, 300, 400, or 500. Document provider method 800 may comprise:

arranging 810 digital communication with one or more of a service provider device, a signing server device, and a user signing device;

obtaining 820 a digest of a document to be signed from the service provider device

providing 830 said digest to the signing server device for determining a digital signature on the document to be signed based on said digest;

obtaining 840 the digital signature on the document to be signed from the signing server device; and/or

providing 850 said digital signature to the service provider device.

Fig. 6c schematically shows an example of an embodiment of a user signing method 900. user signing method 900 may be for use in a signature generation system according to an embodiment, e.g., signature generation system 200, 300, 400, or 500. User signing method 900 may comprise: obtaining 910 a document to be signed made available by a service provider device;

obtaining 920 a confirmation of the document to be signed from a user of the user signing device via a user interface; and/or

providing 930 a user identifier of the user signing device and the confirmation of the document to be signed to a signing server device.

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 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, steps 720 and 730-760 may be executed, at least partially, in parallel. Moreover, a given step may not have finished completely before a next step is started.

A method according to the invention may be executed using software, which comprises instructions for causing a processor system to perform method 700, 800, and/or 900. 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. A method according to the invention may be executed using a bitstream arranged to configure programmable logic, e.g., a field-programmable gate array (FPGA), to perform the method.

It will be appreciated that the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention 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 the method according to the invention. 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 means of at least one of the systems and/or products set forth. Fig. 7a shows a computer readable medium 1000 having a writable part 1010 comprising a computer program 1020, the computer program 1020 comprising instructions for causing a processor system to perform a signing server method, a document provider method, and/or a user signing method, according to an embodiment. The computer program 1020 may be embodied on the computer readable medium 1000 as physical marks or by means of 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. The computer program 1020 comprises instructions for causing a processor system to perform one or more of methods 700, 800, 900.

Fig. 7b shows in a schematic representation of a processor system 1140 according to an embodiment. The processor system comprises one or more integrated circuits 1110. The architecture of the one or more integrated circuits 1110 is schematically shown in Fig. 7b. 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, the service provider device, signing server device, user signing device, document provider device and/or user device may each 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. In an embodiment, the processor circuit may be ARM Cortex M0. 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. It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, 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. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the device claim enumerating several means, several of these means 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 of exemplifying embodiments or to formulas of embodiments, thus increasing the intelligibility of the claim. These references shall not be construed as limiting the claim.