Devices and methods for secure communication

Abstract

Some embodiments relate to secure communication between a device and a server. The device is configured to decrypt encrypted messages using a private key in a secure mode and display the secret shared with the user, along with the decrypted message, on the device's display to indicate to the user that the message is being displayed by software running in the secure mode.

Description

[0001] Cross-reference to related applications

[0002] This application is a U.S. national phase application filed November 3, 2020, under 35 USC §371, for international application PCT / EP2020 / 080729, which claims the benefit of European patent application EP19208505.8, filed November 2019. These applications are hereby incorporated herein by reference. Technical Field

[0003] The currently disclosed subject matter relates to a cryptographic device configured for secure communication with a server, a cryptographic method for secure communication with a server, and a transient or non-transient computer-readable medium. Background Technology

[0004] As more and more transactions are executed on the Internet, the importance of protecting these transactions has become increasingly significant. Several solutions have been proposed to address this issue. For example, secure transactions on the Internet often rely on two-factor authentication (2FA).

[0005] Current two-factor authentication (2FA) schemes used for secure online banking and payment services often use smartphones as the second factor during initial authentication or subsequent transaction verification. As a result, such solutions are vulnerable to attack and offer only weak security guarantees. Specifically, an attacker could compromise the phone (potentially including the kernel) and disrupt the second factor. This also applies to mobile-only banking services and solutions that use a single device (e.g., a PC) to initiate transactions. Attacks can be launched, for example, by exploiting weaknesses in existing software, persuading users to install compromised software, viruses, etc.

[0006] Users are increasingly relying entirely on mobile apps for accessing banking services, purchasing products, or booking travel. The convenience of using web-based payment services via smartphones is undeniable, as users can now access them anytime, anywhere—even when access to a personal computer is impossible. However, this convenience comes at the cost of security guarantees provided by 2FA (Two Factors of Arbitration). Specifically, 2FA often assumes that the two factors remain independent and isolated because it requires a compromise between them to initiate a fraudulent transaction; however, this assumption is often untrue when a single device (such as a smartphone) serves both factors, as an attacker only needs to compromise a potentially vulnerable smartphone to break 2FA, as with mobile phones. The weak separation between factors means that if one factor is compromised, it may be sufficient to compromise all factors.

[0007] If an attacker gains root access on a mobile device, even transactions initiated on a PC are insecure. In this situation, the attacker can replace or tamper with the mobile app, intercept messages, and display misleading information.

[0008] Unfortunately, compromised smartphones are a real threat, especially given the compromised PC, because even when the phone and PC are physically separate, the devices are often not independent. Surprisingly, despite ample evidence of the weak practical application of today's phone-based 2FA, this is by no means a solved problem.

[0009] Even advanced solutions tend to focus on limited threat models that exclude full-scale compromise calls, where an attacker gains root access, infects the kernel, and / or the corresponding app. Given that 2FA is often used in high-value interactions (e.g., banking) and full-system compromise is frequent, such limited threat models are insufficient. Improvements in transaction authenticity are desired, for example, to prevent attackers from initiating transactions on behalf of users or servers undetected.

[0010] While in practice problems often begin with a lack of separation between the two factors, even with strong separation, other equally fundamental issues exist. In particular, a neglected aspect of secure communication is transaction integrity—for example, preventing attackers from modifying the content of exchanged or displayed messages. Even with perfect transaction authentication, a system can still be compromised if transaction integrity is weak. For instance, an attacker could hijack a user's transaction by displaying misleading information on the screen, thus compromising transaction integrity. Summary of the Invention

[0011] Improving secure communication between devices and servers would be beneficial.

[0012] One way to improve both transaction authentication and integrity is to use a processor system configured with normal and secure modes. Data and code in secure mode can be isolated from those in normal mode. If the private key is stored in the secure data section, messages encrypted with the corresponding public key arriving from the server can only be decrypted using the private key and can only be implied by software running in secure mode. While this improves communication security, problems remain. For example, an attacker who has compromised the normal parts of the device can control the information visible to the user. For instance, even if the user believes they have agreed to transaction B, an attacker can still instruct the server to execute transaction A. For example, although a message on the screen instructs the user to, for example, buy a book online, they may not actually be transferring funds to an attacker.

[0013] In this embodiment, the data stored on the device that can only be accessed in secure mode includes not only private keys, for example, for decrypting messages from the server, but also shared secrets, such as secrets shared between the secure mode software and the user.

[0014] Setting a shared secret can be performed during the registration phase. For example, the device can be configured to allow users to set a shared secret, such as when initializing the device, for example, when the device is first started. The registration phase can also be performed when the second-mode software is first installed or configured, etc.

[0015] Sharing secrets can include text, such as words or phrases; sharing messages can include images. For example, a user can type text on a keyboard (e.g., a virtual keyboard on a touchscreen). Alternatively, a user can use their device's camera to take images, such as selfies, pictures of their home, their cat, etc.

[0016] Later, for example, during the usage phase, when an encrypted message is received from the server, the secure mode software can decrypt it and display the message along with a shared secret. Since the shared secret is known only to the user and the secure mode software, this indicates to the user that the message is being displayed by the secure mode software.

[0017] An attacker who has compromised the normal mode software cannot reveal the shared secret. Therefore, integrity is increased. The device, method, or system used to deliver a message from a server to a user can be used in the context of a transaction (e.g., a bank transfer), but also outside of a transaction. For example, the message can be informational. The message can be pushed by the server. For example, the message could notify a user that they need to pick up a new bank card, set up a new hospital appointment, etc. Because the message is displayed along with the shared secret, the user has increased trust in the message.

[0018] The format of the transmitted message and the format of the displayed message do not need to be the same. For example, the message may be compressed and may contain metadata, but the displayed message may be uncompressed or have its metadata stripped.

[0019] Message encryption is preferably combined with a message signature or other authentication elements. For example, secure mode software can decrypt the message and verify the signature on it. Therefore, when the message is presented, the user has already increased trust, not only by decrypting it through secure software but also by verifying it. For example, secure mode may have access to one or more certificates to verify the signature. Certificates (one or more) may be stored in secure mode data, but this is not required; they may be in normal mode or received with the message.

[0020] When used in transactions, such as secure communication, it can be used to authenticate users. This can be a unique authentication, but it can also be combined with other authentication factors, such as credentials, biometrics, etc. For example, an encrypted authentication tag can be received along with an encrypted message. The encrypted authentication tag can also be decrypted by secure mode software (e.g., a second software) using a private key from the secure mode data (e.g., the same key used for the message or a different key). The authentication tag can be included in the message. The latter has the advantage of requiring only one decryption. The encrypted tag and the encrypted message can also be two different communications.

[0021] Note that a transaction can be initiated on a cryptographic device, but this is not required. A transaction can also be initiated on, for example, a PC, as part of a browsing session. For instance, a user might want to make a bank transfer, such as to pay for a product or service, causing the PC to send a message over the Internet to a server (e.g., a bank). The server can respond by sending an encrypted tag and / or an encrypted message to the cryptographic device (e.g., a device different from the initiating device, such as a mobile phone different from the PC).

[0022] Secure mode software (e.g., a second software) can be configured to decrypt the authentication tag. For authentication, the cryptographic device can be configured to send a response to the server that depends on the authentication tag to prove it knows the decryption key. This can be done in several ways.

[0023] First, the response can depend on the tag in several ways. The response can include the tag itself, a hash of the tag, encryption on the tag, a signature on the tag, a MAC address on the tag, and possibly any combination thereof. When the server receives the response, it can verify its relationship to the tag it sent to the device. If the relationship is verified, this increases the sender's trust in the tag and therefore its trust in the private key used to decrypt the encrypted tag. The response may also include a hash of the message.

[0024] Secondly, various methods exist for creating responses. For example, the response can be at least partially computed by secure-mode software. The secure-mode software can then export the response to normal-mode software. For example, the response can be exported in plaintext to normal-mode software, which can then at least partially compute the response. Note that exporting a plaintext tag does not necessarily lead to an attack, even if the normal-mode software is compromised. An attacker may or may not forward the real tag, may or may not modify it, etc., but the attacker cannot prevent the message from being seen by the user. Therefore, the server can inform the user what the tag is for, such as what transaction, such as what bank transfer. If the user does not want the transmission, he or she can stop exporting the tag. The server can be configured to not allow changes to the request after it has sent out the encrypted tag. If it is desired to avoid the plaintext transmission of the tag, it can be encrypted, for example, using a key (e.g., using the server's public key), before being passed from secure mode to normal mode.

[0025] Instead of internally handling the computation of tag decryption to response, the device can also transmit the tag via the user. For example, the decrypted tag can be displayed on the screen along with a shared secret and optionally along with a message from the server. The user knows the tag comes from secure-mode software because it recognizes the shared secret. The user can then enter the tag into some other software that can use the tag to compute the response. This other software can be normal-mode software running on the same device, or even software running on different devices (e.g., PCs, such as PCs used to initiate transactions). Using the user to transmit the tag is particularly advantageous for creating security improvements for legacy software.

[0026] The tag can be any sequence of numbers, such as a random 80-bit sequence, 128-bit, 256-bit, or more or fewer. If the tag is to be transmitted by the user, it is advantageous to choose a sequence of letters, numbers, one or more words, etc., to facilitate transmission.

[0027] Normal and safe modes can be hardware-enforced isolated environments that can even run their own normal and safe operating systems and / or their own normal and safe apps. Existing technologies can be used to create normal and safe modes, such as ARM TrustZone.

[0028] Prototypes of various embodiments have been created and tested. In particular, an embodiment called "SecurePay" has been integrated into ten existing apps. The inventors have found that changes to existing apps (e.g., existing banking apps) are minimal when the secure mode software is in place. Changes typically require modifications to only a small portion of existing apps, such as causing them to accept OTPs from secure mode interfaces instead of OTPs from SMS, etc. Furthermore, if code modification is not possible, such as not permitted, the SecurePay embodiment can still be used as a secure plug-in replacement for existing SMS-based 2FA solutions. For example, the plug-in embodiment can intercept SMS messages and provide the user with a decryption tag. The decryption tag can be entered by the user, and the legacy app is unaware that it has been decrypted by the secure mode software.

[0029] Embodiments such as SecurePay provide security even in devices where all normal-mode software is compromised, while maintaining the convenience of the mobile device. Note that in the embodiments, only a portion of the SecurePay functionality needs to be implemented in secure mode, for example, the functionality for handling the second factor, while the remainder can be the normal-mode portion. In fact, it has been shown that it is possible to create a fully functional but small enough secure-mode application to allow for formal verification.

[0030] The embodiments can be applied to mobile-only transactions and transactions initiated on personal computers, where the mobile device is used only as a second factor. In these embodiments, the cryptographic device is not a mobile phone, but is still an electronic device.

[0031] One aspect of the currently disclosed subject matter relates to secure communication using signatures instead of encryption. For example, in messaging embodiments that are not necessarily used with tags for authentication or 2FA, using signatures instead of encryption may be preferred. Signatures can also be used in conjunction with encryption. Examples of implementations for encryption given herein can be applied to embodiments using signatures or using signatures with encryption, for example, for messages and / or tags received from a server.

[0032] Cryptographic devices can be electronic devices. For example, a cryptographic device can be a computer. It can also be a mobile electronic device, such as a mobile phone. Cryptographic devices can be consumer electronics products, such as set-top boxes, televisions, etc.

[0033] The secure communication methods described in this paper can be applied to a wide range of practical applications. Such applications include: the transmission of sensitive information (e.g., financial or medical information), and the authentication of transactions (e.g., financial transactions or medical appointments).

[0034] On the other hand, it is a cryptographic method for secure communication with a server. The server can be a computer. Embodiments of the method can be implemented on a computer as a computer-implemented method, or on dedicated hardware, or a combination of both. Executable code for embodiments of the method can 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 includes non-transient program code stored on a computer-readable medium for executing embodiments of the method when the program product is run on a computer.

[0035] In an embodiment, the computer program includes computer program code adapted to perform all or part of the steps of an embodiment of the method when the computer program is run on a computer. Preferably, the computer program is implemented on a computer-readable medium.

[0036] Another aspect of the currently disclosed subject matter provides a method for making the computer program available for download. This aspect is used when the computer program is uploaded to, for example, Apple's App Store, Google's Play Store, or Microsoft's Windows Stores, and when the computer program is available for download from such stores. Attached Figure Description

[0037] Additional details, aspects, and embodiments will be described by way of example only with reference to the accompanying drawings. Elements in the drawings are illustrated for simplicity and clarity and are not necessarily drawn to scale. In the drawings, elements corresponding to those already described may have the same reference numerals. In the drawings,

[0038] Figure 1 An example of an embodiment of a communication system is illustrated schematically.

[0039] Figure 2a An example of an embodiment of a cryptographic device is illustrated schematically.

[0040] Figure 2b An example of an embodiment of a cryptographic device is illustrated schematically.

[0041] Figure 2c An example of an embodiment of a cryptographic device is illustrated schematically.

[0042] Figure 3a An example of an embodiment of a cryptographic device is illustrated schematically.

[0043] Figure 3b An example of an embodiment of a cryptographic device is illustrated schematically.

[0044] Figure 3cAn example of an embodiment of a cryptographic device is illustrated schematically.

[0045] Figure 4a An example of an embodiment of the authentication method is illustrated schematically.

[0046] Figure 4b An example of an embodiment of the authentication method is illustrated schematically.

[0047] Figure 5 An example of an embodiment of the cryptographic method is illustrated schematically.

[0048] Figure 6a A computer-readable medium having a writable portion including a computer program, according to an embodiment, is illustrated schematically.

[0049] Figure 6b A representation of a processor system according to an embodiment is shown schematically.

[0050] Figure 1-3c List of reference numerals in figures 6a-6b

[0051] 100 Communication System

[0052] 110 Cryptographic Devices

[0053] 120 Computer Network

[0054] 130, 170 processor systems

[0055] 140, 180 memory

[0056] 150, 190 communication interfaces

[0057] 160 server

[0058] 200-202 Cryptographic devices

[0059] 210 Communication Interface

[0060] 211 Encrypted Message

[0061] 212 Encryption Authentication Label

[0062] 213 Response Message

[0063] 220 First Software

[0064] 231, 232 Normal Mode / Safety Mode Interfaces

[0065] 241 Private Key

[0066] 243 Public Key

[0067] 242 Cryptographic Processing Unit

[0068] 244 Responders

[0069] 250 Display Generator

[0070] 251 Shared Secrets

[0071] 270 Public Hardware

[0072] 271 Monitor

[0073] 272 Input Devices

[0074] 273 tags

[0075] 291 Normal Mode

[0076] 292 Safe Mode

[0077] 300 cryptographic devices

[0078] 311 Monitor

[0079] 312 Input button

[0080] 314 Sharing Secrets

[0081] 315 News

[0082] 316 tags

[0083] 317 Accept button

[0084] 318 Public Key

[0085] 1000 computer-readable media

[0086] 1010 writable portion

[0087] 1020 Computer Program

[0088] 1110 (one or more) integrated circuits

[0089] 1120 Processing Unit

[0090] 1122 Memory

[0091] 1124 Application-Specific Integrated Circuit

[0092] 1126 Communication Components

[0093] 1130 Interconnection

[0094] 1140 Processor System Detailed Implementation

[0095] Although the subject matter disclosed herein allows for many different forms of embodiments, one or more specific embodiments are shown in the accompanying drawings and will be described in detail herein. It should be understood that this disclosure is to be considered as an example of the principles of the subject matter of this disclosure and is not intended to limit it to the specific embodiments shown and described.

[0096] In the following description, for the purpose of understanding, the elements of the embodiments are described in operation. However, it will be apparent that the corresponding elements are arranged to perform the functions described as being performed by them.

[0097] Furthermore, the subject matter disclosed herein is not limited to the embodiments, but also includes every combination of features described herein or recited in mutually different dependent claims.

[0098] Figure 1 An example of an embodiment of the communication system 100 is illustrated schematically. The communication system 100 includes a cryptographic device 110 and a server 160.

[0099] In an embodiment, it may be desirable for server 160 to send messages to device 110, for example, messages intended for use by a user of device 110. For example, the messages may be sensitive, such as relating to financial or medical matters, or they may be security-related, such as requiring authentication of device 110 or its users by server 160. However, if device 110 is compromised, any message could be displayed to a user on a monitor, for example, by unauthorized software running on device 110, and the user might believe that the message originated from server 160. Conventional hardware, and even highly secure hardware (e.g., hardware with normal and secure modes to separate secure and insecure operations), is susceptible to this problem.

[0100] Cryptographic device 110 may include processor system 130, memory 140, and communication interface 150. Server 160 may include processor system 170, memory 180, and communication interface 190. Systems 110 and / or 160 may communicate with each other, external storage devices, input devices, output devices, and / or one or more sensors via computer network 120. The computer network may be the Internet, intranet, LAN, WLAN, etc. The system includes connection interfaces arranged to communicate as needed within or outside the system. For example, the connection interfaces may include connectors, such as wired connectors (e.g., Ethernet connectors, optical connectors, etc.) or wireless connectors (e.g., antennas, such as Wi-Fi, 4G, or 5G antennas).

[0101] Computer network 120 may include those not in Figure 1Additional components shown separately include, for example, routers, hubs, etc. In device 160, communication interface 190 can be used, for example, to send one or more encrypted messages to device 110 and / or receive one or more encrypted responses from device 110. In device 110, communication interface 150 can be used, for example, to receive one or more encrypted messages from server 160 and / or send one or more encrypted responses to server 160. The communication interface can also be used to send unencrypted messages, etc. Messages can be, for example, digital messages received electronically.

[0102] The execution of devices 110 and 160 can be implemented in a processor system, such as one or more processor circuits, like a microprocessor, examples of which are shown herein. Figures 2a-2c The diagrams illustrate functional units that could be functional units of a processor system, such as device 110. For example, these diagrams can be used as blueprints for the possible functional organization of a processor system. In these diagrams, processor circuitry (one or more) is not shown separately from the units. For example, Figures 2a-2c The functional units shown may be implemented, in whole or in part, as computer instructions stored at device 110 (e.g., in the electronic memory of device 110) and executable by the microprocessor of device 110. In hybrid embodiments, the functional units are implemented in hardware, for example as coprocessors (e.g., cryptographic coprocessors), and in software stored and executed on device 110.

[0103] Figure 2a An example embodiment of cryptographic device 200 is illustrated schematically. For example, device 200 can be implemented on a device such as device 110. Device 200 is configured for secure communication with a server. Figure 2a The server is not shown. For example, the server could be server160.

[0104] For example, in one embodiment, the server is configured to securely communicate with a cryptographic device. The server includes a communication interface configured to communicate with the device, a key storage device configured to store a public key corresponding to the private key of the cryptographic device, and a processor system configured to generate a message for the cryptographic device, encrypt the message using the device's public key, and send the encrypted message from the server to the device.

[0105] In an embodiment of device 200, encrypted messages sent from a server are displayed in such a manner that the user of device 200 has increased confidence that the messages are displayed in the secure mode of device 200 and therefore the messages being displayed are unlikely to be compromised by unauthorized software running on device 200 due to an attack. More generally, any cryptographic guarantees implemented for some content as a result of cryptographic processing by a second software (which is for integrity protection (e.g., verification of signatures, MACs, etc.) or confidentiality protection (e.g., decryption)) are extended to the content when the content is displayed along with a shared secret, as explained herein.

[0106] Device 200, and specifically its processor system, is configured with a normal mode and a secure mode. Normal mode and secure mode are sometimes referred to as the normal world and the secure world (and sometimes, for simplicity, as first mode and second mode). Normal mode can be used to run less critical software, such as user applications, games, etc. Secure mode is used to run more critical software, such as software that handles confidential information (such as secret keys). For example, decryption or signing operations can be performed in secure mode. Some applications can be implemented mostly in normal mode but partially rely on components in secure mode. For example, a banking application can run mostly in normal mode, but may rely on the parts running in secure mode when transactions need to be executed.

[0107] exist Figure 2a The diagram shows the partitions in normal and safe modes illustrated by vertical dashed lines. Safe mode 292 is shown on the left, and normal mode 291 is shown on the right. Operations that can be performed in safe mode are depicted at safe mode 292, while operations that can be performed in normal mode are depicted at normal mode 291. Software running in normal mode can be referred to as first software, and software running in safe mode can be referred to as second software. Safe mode can also be referred to as a Trusted Execution Environment (TEE).

[0108] Data and code are isolated in secure mode from normal mode. For example, in secure mode, private key 241 and shared secret 251 can be stored. This means that the first software running in normal mode cannot access this data. Software running in secure mode can access this data.

[0109] Private key 241 can correspond to the public key of a cryptographic device available to the server. For example, a message from the server can be encrypted using the public key. Private key 241 and the public key together form a so-called public / private key pair.

[0110] Setting a shared secret can be performed during the registration phase. For example, a device can be configured to allow users to set a shared secret, such as when initializing the device, for example, when the device is first started. The registration phase can also be performed when the second-mode software is first installed or configured. The latter may be later than the device's first use, or even much later. If the device has already been compromised at that time, the displayed messages still cannot be trusted: when a user believes he is entering his shared secret into the secure-mode software, he may actually be entering it into an attacker's software. However, this still has the advantage that if the device is not compromised at that time, the messages can be trusted even if the device is compromised later. Generally, the closer the registration phase is to the device's trusted (e.g., original, initialized) state, the better the trustworthiness of the messages. However, installing the system is still always better than not installing it.

[0111] In normal mode, the first software executes; in safe mode, the second software executes. To transfer information from normal mode to safe mode and vice versa, an interface can be installed. For example, Figure 2a Normal mode / secure mode interfaces 231 and 232 are shown, through which messages can be passed from one mode to another. Various access restrictions or controls can be imposed on these interfaces. For example, the first software does not have access to the second software's data unless the second software places it on the interface to pass it to normal mode. For example, code passed from normal mode to secure mode can be executed only if it is signed with the private key of an appropriate authorized authority (e.g., the manufacturer of device 200). For example, interfaces 231 and 232 can be formed from memory that can be accessed equally in both secure and normal modes.

[0112] Preferably, the security mode is a hardware-enforced isolation environment. For example, a hardware bit can be used to implement both normal and security modes, the bit being configured to cause flipping the bit to alter data access and transfer control to either first or second software as needed. For example, device 200 may have electronic memory accessible only in security mode, e.g., if the bit is in a secure position. For example, a first operating system of device 200 may run in normal mode, and a second operating system of device 200 may run in security mode.

[0113] Although code and data can be strictly separated in device 200, software running in both modes can still have access to the same hardware or partial access to the same hardware. Figure 2aCommon hardware 270, usable by both normal and safe mode software, is shown. For example, common hardware 270 may include a display 271. Both the first and second mode software can be displayed on display 271. However, the common hardware is shielded to avoid creating a reverse channel between the two modes. For example, software running in normal mode is prevented from capturing the second software's display of messages on the screen. Similarly, while the second software is running, software running in normal mode can be prevented from being overlaid on the display. For example, in one embodiment, the display can be operated from a frame buffer accessible from normal mode and from a frame buffer accessible from safe mode instead of normal mode. In this way, safe mode can override control over access to the display if needed.

[0114] Before the system switches back to normal mode, any information that may have remained in resources used by software running in safe mode and could be accessed by software running in normal mode can be removed from sensitive information (e.g., shared secrets, message content). For example, suppose a single frame buffer is used to drive the display, and secure software is running in safe mode, preventing normal software from accessing the frame buffer. After displaying, for example, shared secrets and messages, the frame buffer can be cleared before the system switches back to normal mode; specifically, shared secrets and / or messages and / or tags can be removed.

[0115] In this field, many examples of safe modes, safe mode software, etc., are known—sometimes referred to as Trusted Execution Environments (TEEs). A TEE is a secure execution environment that can run in parallel with the operating system of a device such as a smartphone or similar device. Several hardware vendors have introduced different hardware-assisted TEEs: Intel Identity Protection Technology, Intel Software Protection Extensions, ARM TrustZone, etc. Many devices support TrustZone-based TEEs. For example, a typical TEE can manage trusted applications, providing security services to untrusted applications running on the normal mode operating system of a mobile device. For example, APIs for creating trusted applications that run in safe mode can be provided.

[0116] For example, in ARM TrustZone, a TEE can be provided by enabling the system to operate in parallel in two execution domains: a normal world and a secure world. The current state of the system can be determined by the value of the non-secure (NS) bit of the security configuration register. The secure domain can have privileged access to all hardware resources, such as CPU registers, memory, and peripherals, while the normal domain is constrained. An additional CPU mode called a monitor can exist, acting as a gatekeeper between the two domains, such as an interface. This monitor mode can also be privileged regardless of the state of the NS bit. Similarly, the memory address space can be divided into regions that can be marked as secure or insecure, for example, using the TrustZone address space controller. Peripherals can be marked as accessible to the secure world, for example, by programming the TrustZone protection controller.

[0117] To switch from the normal world to the secure world, the system can initially switch to monitoring mode by executing a Security Monitoring Call (SMC). This allows monitoring mode to verify whether switching from one world to another should be permitted. If the request is deemed valid, it modifies the NS bit accordingly and completes the world switch.

[0118] Figure 2a A communication interface 210 configured to communicate with a server is shown. Encrypted or unencrypted messages can be transmitted between the server and device 200. Interface 210 may be a computer network interface. Interface 210 can operate in normal mode, necessitating the assumption that its content may be compromised. An encrypted message 211 is received from the server. The encrypted message 211 is encrypted using the public key of a cryptographic device. This means that it can only be decrypted using its corresponding private key (i.e., private key 241). Since private key 241 is only accessible in secure mode, it can be assumed that an attacker cannot decrypt the encrypted message 211. However, instead of decrypting message 211, an attacker could also attempt to mislead the user of device 200 by displaying information that does not correspond to the true content of message 211. However, device 200 may also have countermeasures against this type of deception.

[0119] Note that besides encryption, message 211 can be cryptographically protected in a variety of other ways. For example, message 211 can be integrity protected, such as by being signed by the server (e.g., with the server's private key) or by including a message authentication code (e.g., under encryption).

[0120] The first software 220 operates in normal mode (e.g., first mode). The first software 220 can be configured to forward encrypted message 211 to the second software operating in secure mode (e.g., second mode). For example, message 211 can be transmitted via one or more interfaces 231 / 232.

[0121] exist Figure 2a The left side illustrates different components of the second software. For example, the cryptographic processing unit 242 can operate in a secure mode, for example, included in the second software. The cryptographic processing unit 242 is configured to perform cryptographic operations, such as decryption or verification. For example, the cryptographic processing unit can be implemented using software (e.g., a cryptographic library) or, for example, at least partially in hardware using a cryptographic coprocessor.

[0122] The cryptographic processing unit 242 can be configured to decrypt the encrypted message 211 using the private key 241. The private key 241 is stored in secure mode data, preventing the first software 220 from accessing the key 241. For example, the decryption algorithm can be an asymmetric decryption algorithm, such as RSA private key decryption, elliptic curve private key decryption, etc.

[0123] The encrypted message 211 can also be signed, for example, using the server's private key. The cryptographic processing unit 242 can be configured to verify the signature on message 211 using public key 243. Public key 243 corresponds to the server's private key. Public key 243 can be stored in secure mode data such that the first software 220 does not have access to key 241 and therefore does not affect how verification will be performed. Although public key 243 does not necessarily need to be stored in secure mode data; it can instead be stored in the normal world, or it can be received with message 211. In the latter two cases, the cryptographic processing unit 242 can perform some checks on the authenticity of public key 243, for example, verifying that key 243 is part of a certificate chain. The root of the certificate chain can be stored in secure mode data. For example, the signature verification algorithm can be an asymmetric algorithm, such as RSA public key verification, elliptic curve public key decryption, etc.

[0124] Whether to use public key 243 to verify the signature or private key 241 to decrypt the message, or whether to use both public key 243 and private key 241 to verify the signature and decrypt the message, depends on the application. Various examples are given below and applied to various implementations.

[0125] After message 211 has been decrypted, the display generator creates display content and sends it to display 271. For example, the display content includes the message and a shared secret 251. Like private key 241, shared secret 251 is also stored in the secure mode data, making it inaccessible to normal mode software (e.g., the first software). The shared secret is a secret shared with the user. If the user sees the secret, he knows that the display was caused by software running in secure mode. Since unauthorized software is more likely to enter secure mode than normal mode, this increases the user's trust in the display content he sees, for example, that it was generated by authorized software, such as the second software instead of the first.

[0126] Device 200 is preferably configured such that when the first software is retained by the second software (e.g., operated by the second software), the first software cannot write to the display. Similarly, the second software cannot read from the display to obtain the shared secret 251.

[0127] For example, if a user sees his shared secret 251 and the instructions from his bank, his doctor, his husband or wife, etc., he knows that the message was displayed by second software, which in turn means it has been decrypted by private key 241, and therefore means that an attacker operating in normal mode cannot read the message. Similarly, if a signature is verified on the message, the user who sees the message can be assured that the message was indeed signed by someone who knows the private key corresponding to the verification public key; for example, the message may be authentic. The verification public key (e.g., key 243) can be stored in secure mode data, but can also be received from the normal world, for example, in the form of one or more certificates.

[0128] The second software can be configured to display the password status of a message in the displayed content, such as whether the message is encrypted and / or signed and by whom.

[0129] A device is called a server because it performs the function of sending encrypted and / or signed messages (one or more) to a cryptographic device. A server can typically comprise a standalone computer, but can also be implemented in a mobile device (e.g., another phone). In this scenario, the device and the server can alternate between these roles while sending messages to each other.

[0130] Figure 3a and 3b An exemplary cryptographic device is shown. Shared secret 314 and message 315 are shown on the display. (Label 316 and button 317 are optional and discussed elsewhere in this document).

[0131] Return to Figure 2a As an example, a shared secret could be, for example, secret text previously typed by the user or selected for the user (e.g., randomly selected). A shared secret could also be, for example, an image previously shown to the user. The image could be randomly generated, for example, by randomly juxtaposing image elements (e.g., triangles, circles, etc.). For example, the image could be captured by a camera of device 200. For example, the camera could be part of public hardware but still under the control of the second software, for example, under temporary control. For example, a user could take a selfie or image of a landmark (e.g., their garden or balcony) as a shared secret, etc. Preferably, the shared secret is known only to the user and the second software.

[0132] In an embodiment, the startup code of device 200 can be configured to receive a shared secret from the user during an initial startup sequence configured therefor. For example, when assuming the device is in its original state, the shared secret can be loaded into the TEE during initial startup or a complete system reset. Since only the trusted code knows the secret, the user knows that if the device displays an image and / or text on the screen, the trusted code is in control and no other code is running. Just before returning control to the normal world, if the memory is accessible by the first mode software, the second software can remove the shared secret from the memory.

[0133] Private key 241 and its corresponding public key can be generated by second software running in secure mode. The private key (e.g., private key 241) can be stored in data within secure mode. The public key can be sent to first software configured to send the public key to a server.

[0134] In this embodiment, the public key may alternatively or similarly be displayed on the display along with the shared secret, for example, in a computer-readable format. The optically readable format may be a QR code. This has the advantage that the user can verify, before an authorized institution, that the displayed QR code is indeed the public key corresponding to the private key. This also has the advantage that the authorized institution (e.g., a bank) cannot be deceived into believing that an attacker's key is the user's key.

[0135] Figure 3c An example is shown. A QR code 318 is shown, which encodes the public key corresponding to private key 241. It is also shown in shared secret 314. Since the shared secret is stored only in data prat accessible only in secure mode (e.g., in a secure world), the screen cannot be displayed using normal mode codes, even if the normal mode codes are compromised. A user of device 300 can verify shared secret 314 and then scan the screen. In this way, the user is assured that the public key the scanner will record (e.g., an authorized institution such as a bank) is indeed the public key corresponding to their own private key (e.g., private key 241), and not an attacker's key.

[0136] In one embodiment, the user can remove (e.g., sweep away) secret 314 before scanning the screen to avoid publicly sharing the secret.

[0137] In one embodiment, the first software 220 makes a request to the server, for example, a request for a bank transfer. In response, the server may send an encrypted message. For example, the encrypted message may depend on the request. For example, the request may include a summary of the request, such as the amount of the bank transfer and / or the expected recipient. For example, the request may be a request for a hospital appointment. In this case, the message may also include information about the request or about the availability at the hospital.

[0138] For example, the first software 220 can be configured to send a transaction request to a server and receive an encrypted authentication tag 212 in response to the transaction request.

[0139] In an embodiment, device 200 may include additional visual indicators, such as LEDs, configured to indicate whether the content of the display originates from a secure mode. For example, the indicator may turn on if the device switches to secure mode. This can be used in addition to, or even instead of, sharing a secret. Device 200 may be configured such that the first software does not have control over the visual indicators.

[0140] Figure 2b An example embodiment of cryptographic device 201 is illustrated schematically, in which the device authenticates itself to a server. The cryptographic device can therefore be referred to as an "authentication device." Device 201 can be identical to device 200, except where indications are given specifically regarding multiple additions.

[0141] Device 201 is configured to receive an encrypted authentication tag 212 from a server, in addition to or in lieu of a message. The encrypted authentication tag can be encrypted using the public key of a cryptographic device. This can be the same public key corresponding to private key 241, but it can also be a different key. For example, device 201 can include a message private key 241 and a different tag private key.

[0142] However, the encrypted authentication tag is also sent from normal mode to secure mode, where it can be decrypted by the cryptographic processing unit 242. The responder 244 can use the decrypted tag to generate a response message. For example, the response message may include the decrypted tag, or a hash of the decrypted tag, or a signature on the decrypted tag, or encryption of the decrypted tag (using a different key, e.g., using the server's public key). The response 213 can then be sent back to normal mode and from there to the server. When the server receives the response message 213, it can infer that the generator of the response message knew the decrypted tag and therefore knew the tag's private key, such as key 241. Thus, the server can increase its trust that the message has reached the correct device and even its trust that the message is displayed on the screen.

[0143] For example, in one embodiment, the data in the secure mode may include the server's public key. The second software can be configured to encrypt the authentication tag using the server's public key. For example, in one embodiment, the second software can be configured to sign the authentication tag using its own private key (e.g., key 241). The signing can also be performed by the first software, but using a different key, for example, a different private key stored in normal mode.

[0144] The responder 244 may optionally receive input from the input device 272. The input device 272 may be a button, key, keyboard, touchscreen, mouse, pointer, etc. Using the input device, the user can indicate that he / she has read a message or that he / she has agreed to a message. For example, the user can indicate that he / she agrees to a transaction indicated in a message. Figure 3b An accept button 317 is shown displayed on a touchscreen monitor. By touching button 317, the user instructs him to accept the transaction. The monitor may also include a reject or cancel button. Instead of touchscreen buttons, such as accept or reject buttons, other input devices, such as mechanical buttons 312, may be used.

[0145] Encrypted messages can be received in conjunction with encrypted authentication tags; for example, both can be part of a larger message, and they can be sequential, etc. They don't necessarily need to come from the same source, but this will be typical. The tag and message can be within the same encrypted message, which may also have a signature.

[0146] Once the second software has displayed the message and received a response to the displayed message from the user of device 201, an authentication tag can be sent to the first software based on that response. The latter can be done in a plain manner, but preferably in a password-protected manner, for example, encrypted for confidentiality.

[0147] Tags and / or messages can be received via a different communication channel than the communication channel used for response messages to the server. For example, in one embodiment, encrypted authentication tags and / or messages can be received via a first type of computer communication interface (e.g., SMS), and the authentication message is sent via a second type of computer communication interface (e.g., the Internet), different from the first type. Tags may include random numbers, unique numbers, etc.

[0148] Note that in device 201, the decryption tag or data calculated from the decryption tag can be sent to the first software via a software interface (e.g., one or more interfaces 231 / 232) inside device 201, for example, in the form of a message including the authentication tag.

[0149] In this embodiment, message 213 may be one factor in a two-factor authentication scheme. For example, the first software and / or the second software may be configured to receive additional authentication factors, such as credentials or biometrics, from the user of the authentication device before authentication with the server is completed. Additional credentials may also, or alternatively, be included in the response message to the server.

[0150] Figure 2c An example embodiment of cryptographic device 202 is illustrated schematically. Device 202 can be identical to device 201, except for the manner in which the tag is forwarded to the first software.

[0151] In device 202, a second piece of software (e.g., display generator 250) can be configured to display authentication tags on a display. A responder is now optional and can be used, for example, to terminate the display of messages and / or tags.

[0152] The user is now expected to enter the displayed tag 273 in the first software. Note that in this scenario, the software receiving the encrypted authentication tag 212 and the software using the decrypted tag can be different. For example, the first software can be configured to receive the authentication tag from the user via the input interface of device 202 (e.g., input device 272). For example, the second software can display the decrypted tag as... Figure 3a Tag 316. Additional software (e.g., another first software) can receive the tag as input from the server and use it, for example, to authenticate with the server. This additional software can run on a PC or a cryptographic device.

[0153] Device 202 is particularly useful for working with legacy software. For example, consider an existing mobile phone with existing software (such as banking software) installed. The software expects the user to enter an authentication tag received via an SMS message. To upgrade the system to higher security, instead of entering an encrypted tag, an encrypted tag can be sent. The encrypted tag (e.g., the entire SMS message) is forwarded to a second software, where it is decrypted and the tag is displayed, for example, along with the message and a shared secret. If the user trusts it, he now enters the decrypted tag in the original banking app. The banking app will behave as if the tag was received via the SMS interface, but in reality, it was passed through the second software. For example, even without changing the underlying security, the banking app's security is increased.

[0154] Tags can include sequences of numbers or letters, or so-called one-time passwords (OTPs).

[0155] The principles described in this article can be used to enhance cryptographic confidentiality and / or cryptographic integrity protection for data received from a server. This can be done by displaying the processed data along with a shared secret, thereby increasing trust that the second software has indeed performed the desired cryptographic processing. Therefore, if, for example, cryptographic integrity protection fails, the message will not be passed to the next step, such as message display. The exact combination of encryption and signing that can be used depends on the application, but several examples are given below.

[0156] You can receive signed messages from the server. Verify the message using the server's public key (e.g., key 243). Key 241 is optional. If the signature is incorrect, the signed message is discarded.

[0157] You can receive encrypted and signed messages from the server. Verify the messages using the server's public key (e.g., key 243) and private key 241.

[0158] You can receive encrypted and unsigned messages from the server, but the public key corresponding to private key 241 is kept secret, for example, known only to the second software and the server.

[0159] A signed and / or encrypted message, along with an encrypted tag, can be received from the server. The message is verified and / or decrypted using the server's public key (e.g., key 243), and the tag is decrypted using private key 241. In this case, care must be taken to ensure that the link between the message and the tag is not compromised. For example, the signature on the tag can be linked to the message, for instance, by including the hash of the message in the signature. Another way to address this is to link the response to the message, for example, by signing the response using private key 241, which depends on both the tag and the message. For example, hashes on both the message and the tag could be included. The server can then verify that the correct message was executed.

[0160] A single message can include the information to be displayed and a label. A single message can be encrypted. Without a signature, it is conceivable that an attacker could alter the message without detection. However, by doing so, he could also potentially alter the label. By returning a label or tag, the device implicitly confirms that the correct information has been displayed. A single message can be replaced by multiple messages, for example, by cryptographically linking them.

[0161] As a final example, a single message can include the information to be displayed and a label. The single message is encrypted and provided with a signature. The response includes functions for the label and the message, such as the label and the message itself or a hash. The server verifies the functions for the label to authenticate the functions for the cryptographic device and the message, verifying that the correct message has been displayed. The functions for the message can be executed in secure mode. To prove the latter, the response can also be signed using the private key of the cryptographic device.

[0162] In various embodiments of devices 110, 160, 200, 201, and 202, a communication interface can be selected from a variety of alternatives. For example, the interface may be a network interface to a local area network or wide area network (e.g., the Internet), a storage interface to an external data storage device, a keyboard, an application programming interface (API), etc.

[0163] Devices 110, 160, 200, 201, and 202 may have a user interface, which may include well-known elements such as one or more buttons, a keyboard, a display, a touchscreen, etc. The user interface may be configured to accommodate user interactions for configuring the system, such as requesting or responding to requests, messages, etc.

[0164] Storage devices can be implemented as electronic storage devices (such as flash memory) or magnetic storage devices (such as hard drives). A storage device may include multiple discrete memories that together constitute the storage device. A storage device may include temporary storage, such as RAM. A storage device may be a cloud storage device.

[0165] Server 160 can be implemented in a single device. Devices 110, 160, 200, 201, and 202 typically include a microprocessor that executes appropriate software stored in the system; for example, this software may have been downloaded and / or stored in a corresponding memory, such as volatile memory like RAM or non-volatile memory like flash memory. Alternatively, the system can be implemented wholly or partially as programmable logic, such as a field-programmable gate array (FPGA). The system can be implemented wholly or partially as a so-called application-specific integrated circuit (ASIC), such as an integrated circuit (IC) customized for its specific purpose. For example, the circuitry can be implemented in CMOS, for example using a hardware description language such as Verilog, VHDL, etc. In particular, devices 110, 160, 200, 201, and 202 may include circuitry for evaluating cryptographic primitives, such as encryption, decryption, signing, and verification.

[0166] The processor circuitry can be implemented, for example, in a distributed manner as multiple sub-processor circuits. Storage devices can be distributed across multiple distributed sub-storage devices. Part or all of the memory can be electronic memory, magnetic memory, etc. For example, the storage device can have volatile and non-volatile portions. A portion of the memory can be read-only.

[0167] Several additional optional refinements, details, and embodiments will be described below as examples of possible embodiments.

[0168] Figure 4a and 4b An example of an embodiment of the authentication method is illustrated schematically. The accompanying drawing shows user 401 and server 410, in this case, a bank. The cryptographic device is shown in two modes: when operating in normal mode 421 and when operating in secure mode 422. However, parts 421 and 422 are the same device.

[0169] Figure 4a Support software 431 and legacy software 432 are shown in normal mode. In safe mode, a second software runs, but this is not shown separately in the diagram. (The arrows are in...) Figure 4a The following is described:

[0170] 451: The user initiates a transaction at point 431 in the software.

[0171] 452: Software 431 forwards the request to server 410.

[0172] 453: Server 410 sends an encrypted message, including, for example, OTP and request digest.

[0173] 454: Software 431 detects encrypted messages, such as SMS, and invokes secure mode software.

[0174] 455: The user verifies the transaction details and obtains the OTP from the display.

[0175] 456: The user enters OTP in software 432.

[0176] 457: Software 432 forwards OTP to confirm the transaction.

[0177] Figure 4b The first software 441 is shown in normal mode. In this case, there is no legacy software; instead, this embodiment is integrated. Arrows are drawn at... Figure 4b The following is described:

[0178] 461: The user initiates a transaction at point 441 in the software.

[0179] 462: Software 441 forwards the request to server 410.

[0180] 463: Server 410 sends an encrypted message, including, for example, OTP and request digest.

[0181] 464: Software 441 detects encrypted messages, such as SMS, and invokes the safe mode software.

[0182] 465: The user verifies the transaction details and clicks "Accept".

[0183] 456: The second software sends the signed OTP to software 441.

[0184] 457: Software 441 forwards the signed OTP to confirm the transaction.

[0185] Note that in Figure 4a In this context, OTP is transmitted via the user, but in Figure 4b In this configuration, OTP is transmitted via an internal channel. Variations as described herein can be used; for example, instead of OTP, any tag can be used, and the response can be computed differently from the tag. The display preferably shows the shared secret in security mode 422.

[0186] According to embodiments, several prototypes called "SecurePay" have been built and tested. These embodiments have the advantage of ensuring the authenticity of transactions by having users cycled through them. SecurePay uses TEEs (such as ARM's TrustZone) to create a hardware-enforced isolation environment. SecurePay uses the authenticity provided by public-key cryptography and the TEE to protect the integrity of transactions. SecurePay relies on a software-based secure display implementation whose output can only be generated by legitimate code that is thus identifiable by the user. SecurePay provides a tamper-proof mechanism implemented by the TEE, allowing users to securely register with service providers that allow authentication (e.g., via two-factor authentication (2FA)).

[0187] To provide compatibility, SecurePay can utilize SMS as a communication channel between users and service providers, and provides a normal-world component (SecurePay app) to deliver received encrypted SMS messages to the SecurePay trusted app (Ta) within the TEE. While this may be beneficial, service providers do not need to modify their mobile apps to utilize SecurePay.

[0188] Upon receiving the encrypted OTP and transaction digest, the user can invoke the SecurePay app to display the decryption message on the secure screen (controlled by the TEE).

[0189] Two different types of implementations were tested during the operation: one was a completely transparent plug-and-play replacement of the existing SMS-based solution, and the other required minor modifications to the service provider's app but provided full integration to simplify user interaction.

[0190] Insert replacement mode in Figure 4aThe diagram illustrates this. First, the user initiates a transaction from the app on her phone (or in a browser running on her PC). The service provider receives the request and responds with an SMS containing an encrypted message (using the user's SecurePay public key), including a transaction summary and the OTP. SecurePay's secure app receives the SMS and launches a trusted UI to display the transaction summary and OTP to the user. Once the user verifies the authenticity of the transaction, she can switch to the service provider's app and access the OTP, just as she would with an existing SMS-based OTP. The OTP is then forwarded to the service provider, and if it matches the OTP previously sent by the provider, the transaction is successfully completed. This version of SecurePay does not require any modifications to the service provider's app on the phone, but it does require the user to remember (or record) the OTP and enter it into the service provider's mobile app (or web interface) to confirm the transaction. Fortunately, psychological research has shown that humans can easily remember an average of seven items in their short memory. Currently, most services use fewer numbers (5 to 6) as OTPs.

[0191] SecurePay can completely hide OTP by making minor modifications to the service provider's app to fully integrate with SecurePay. Figure 4b This diagram illustrates a possible sequence for confirming a transaction in this version of SecurePay. The main difference is that the service provider's app communicates directly with the SecurePay trusted app. Similar to previous versions, the user initiates a transaction using the service provider's app. The service provider then sends an SMS with a cryptographic digest and an OTP to the phone. Since we didn't want to increase SecurePay's codebase, we have the service provider's app (instead of SecurePay) receive this information (via SMS or the internet) and forward it to the SecurePay trusted app. The SecurePay trusted app decrypts the message and shows the user a transaction digest (but not the OTP). The only thing the user needs to do is accept or reject the transaction after viewing the digest. The SecurePay trusted app then transparently signs the OTP and sends it to the service provider's app, which in turn forwards the signed OTP to the service provider. Upon receiving the signed OTP, if the OTP matches a previously sent OTP, the service provider completes the transaction. This version of SecurePay offers more convenience to the user but requires minor modifications to the service provider's app (approximately 20 lines of code on average).

[0192] Enabling SecurePay with an actual service may involve passing a public key to the service. In cases where a user owns multiple devices, all devices can register using a SecurePay-protected service. Registration can occur when a user installs a client component (e.g., a mobile application) on their device. For successful registration, the user securely passes their public key to the service—not necessarily with confidentiality in terms of integrity.

[0193] After installing the SecurePay mobile app, users can invoke SecurePay TA to display a QR code of the public key on the trusted screen. Note that users can ensure the display is currently controlled by the trusted app by verifying the personalized image or secret text before sharing it with the bank. Finally, the bank simply scans the QR code to securely retrieve the public key from the user's device.

[0194] Even if the mobile device may have been compromised during registration, it prevents attackers from using the user's account to register their own public key.

[0195] Note that registering for SecurePay is comparable to, or even simpler than, registering for many other payment services. For example, many banks require hardware tokens to enable e-banking. More importantly, SecurePay's threat model is far stronger than that of existing systems—protecting users from attacks originating from completely compromised devices, where attackers could even gain control of the device's operating system kernel.

[0196] Figure 5 An example of an embodiment of cryptographic method 500 is illustrated schematically. Method 500 may be computer-implemented and includes:

[0197] - Executing (510) the first software in the normal mode of the processor system, the processor system being configured with the normal mode and a secure mode, wherein data and code in the secure mode are isolated from those in the normal mode, and the data in the secure mode includes at least a private key and a secret shared with the user, the execution of the first software comprising:

[0198] - Receive an encrypted message (511) from the server, the encrypted message being encrypted using the public key of the cryptographic device corresponding to the private key.

[0199] - Forward the encrypted message (512) to the second software, and

[0200] - Execute the second software (520) in the safe mode, the execution of the second software includes:

[0201] - Decrypt the encrypted message using the private key stored in the data of the security mode (521).

[0202] - Display the shared secret along with the message on the display (522) to indicate to the user that the message is being displayed by software running in the safe mode.

[0203] Variations of this method of interest can be obtained by performing signature verification in addition to decrypting the message.

[0204] For example, the cryptographic method can be a computer-implemented method. For example, the execution of the first and second software can be done on a processor system (e.g., a processor, such as a microprocessor). For example, receiving and displaying can use hardware such as a receiver interface, antenna, etc., a display, screen, or display interface. For example, forwarding can use an internal forwarding mechanism such as a bus, API, controller, etc. For example, decryption can use a cryptographic coprocessor. The size of the private key can depend on the specific asymmetric encryption / decryption scheme chosen, the platform, the desired level of security, etc. For example, for ElGamal, a key size of 768 bits or less or more can be used. For example, for RSA, 2048 bits or less, or more, can be used, and so on. Asymmetric encryption / decryption can be used in conjunction with, for example, a temporary symmetric key of 128 bits or less or more.

[0205] Many different ways of executing the method are possible, as will be apparent to those skilled in the art. For example, the steps may be executed in the order shown, but the order of the steps may vary or some steps may be executed in parallel. Furthermore, other method steps may be inserted between steps. The inserted steps may represent a refinement of the method as described herein, or may be unrelated to the method. For example, some steps may be executed at least partially in parallel. Moreover, a given step may not be fully completed before the next step begins.

[0206] Embodiments of the method can be executed using software, which includes instructions for causing a processor system to execute method 500. The software may include only those steps taken by a specific sub-entity of the system. The software may be stored on a suitable storage medium, such as a hard disk, floppy disk, memory, optical disk, etc. The software may be transmitted as a signal along a wire, wirelessly, or using a data network (e.g., the Internet). The software may be available for download and / or for remote use on a server. Embodiments of the method can be executed using a bitstream arranged to configure programmable logic, such as a field-programmable gate array (FPGA), to execute the method.

[0207] It will be appreciated that the currently disclosed subject matter also extends to computer programs, particularly computer programs on or in a carrier suitable for putting the currently disclosed subject matter into practice. Programs may take the form of source code, object code, intermediate source code, and object code such as partially compiled form, or any other form suitable for embodiments of the implementation of the methods. Embodiments relating to computer program products include computer-executable instructions corresponding to each processing step of at least one of the illustrated methods. These instructions may be subdivided into subroutines and / or stored in one or more files that may be statically or dynamically linked. Another embodiment relating to computer program products includes computer-executable instructions corresponding to each of the devices, units, and / or portions of at least one of the illustrated systems and / or products.

[0208] Figure 6a A computer-readable medium 1000 is shown having a writable portion 1010, which includes a computer program 1020 comprising instructions for causing a processor system to execute a method for secure communication according to an embodiment. The computer program 1020 may be implemented as a physical mark on the computer-readable medium 1000 or by magnetizing the computer-readable medium 1000. However, any other suitable embodiments are contemplated. Furthermore, it will be appreciated that although the computer-readable medium 1000 is shown herein as an optical disc, the computer-readable medium 1000 may be any suitable computer-readable medium, such as a hard disk, solid-state storage, flash memory, etc., and may be non-recordable or recordable. The computer program 1020 includes instructions for causing a processor system to execute the method for secure communication.

[0209] Figure 6b The illustration schematically depicts a processor system 1140 of a cryptographic device according to an embodiment, or a method for secure communication. The processor system includes one or more integrated circuits 1110. Figure 6bThe diagram schematically illustrates the architecture of one or more integrated circuits 1110. Circuit 1110 includes a processing unit 1120 (e.g., a CPU) for running computer program components to perform methods according to embodiments and / or implement modules or units thereof. Circuit 1110 includes a memory 1122 for storing programming code, data, etc. A portion of the memory 1122 may be read-only. Circuit 1110 may include a communication element 1126, such as an antenna, a connector, or both. Circuit 1110 may include some or all of an application-specific integrated circuit 1124 for performing some or all of the processes defined in the methods. The processor unit 1120, memory 1122, application-specific IC 1124, and communication element 1126 may be interconnected with each other via an interconnection 1130 (e.g., a bus). The processor system may be arranged for contact and / or contactless communication using antennas and / or connectors, respectively.

[0210] For example, in one embodiment, the processor system 1140 (e.g., a cryptographic device) may include processor circuitry and memory circuitry, with the processor arranged to run software stored in the memory circuitry. For example, the processor circuitry may be an Intel Core i7 processor, an ARM Cortex-R8, etc. In another embodiment, the processor circuitry may be an ARM Cortex M0. The memory circuitry may be ROM circuitry or non-volatile memory, such as flash memory. The memory cells may be volatile memory (e.g., SRAM memory). In the latter case, the device may include a non-volatile software interface (e.g., a hard disk drive, a network interface, etc.) arranged to provide the software.

[0211] As used herein, the term "non-transient" will be understood to exclude transient signals but includes all forms of storage devices, including volatile and non-volatile memories. Although device 1110 is shown as including one of each described component, various components may be replicated in various embodiments. For example, processor unit 1120 may include multiple microprocessors configured to independently perform the methods described herein, or configured to perform steps or subroutines of the methods described herein, such that multiple processors cooperate to achieve the functions described herein. Furthermore, in the case where device 1110 is implemented in a cloud computing system, various hardware components may belong to separate physical systems. For example, processor 1120 may include a first processor in a first server and a second processor in a second server.

[0212] The following numbered clauses are not claims, but rather include contemplated examples. For instance, during the examination of this application or any further application derived therefrom, new claims may be formulated from these clauses and / or combinations of these clauses and / or features derived from the specification or claims.

[0213] 1. A cryptographic device configured for secure communication with a server, the device comprising:

[0214] - A communication interface configured to communicate with the server.

[0215] - A processor system configured with a normal mode and a secure mode, wherein data and code in the secure mode are isolated from those in the normal mode, and the data in the secure mode includes at least a private key corresponding to the public key of the cryptographic device and a secret shared with the user of the device, wherein...

[0216] -Execute the first software in the normal mode, the first software being configured to:

[0217] - Receive an encrypted message from the server, the encrypted message being encrypted using the public key of the cryptographic device.

[0218] - Forward the encrypted message to the second software.

[0219] - The second software is executed in the safe mode, and the second software is configured to:

[0220] - Decrypt the encrypted message using the private key stored in the data of the security mode.

[0221] - The shared secret is displayed on the display of the cryptographic device along with the message to indicate to the user that the message is being displayed by software running in the secure mode.

[0222] 2. The cryptographic device described in Clause 1 is also configured to authenticate with the server.

[0223] - The authentication software is configured for use in the normal mode:

[0224] - Receive an encrypted authentication tag from the server, the encrypted authentication tag being encrypted using the public key of the cryptographic device.

[0225] - Enables the encryption authentication label to be decrypted by the second software.

[0226] - Send an authentication message, depending on the authentication tag, to the server to authenticate the cryptographic device.

[0227] - The second software is configured to be used in the security mode:

[0228] - Decrypt the encrypted authentication tag using the private key corresponding to the public key.

[0229] 3. The cryptographic device according to Clause 2, wherein the encrypted message is received in cooperation with the encrypted authentication tag, and the second software is configured to:

[0230] - Obtain a response to the displayed message from the user of the cryptographic device.

[0231] - The authentication token is sent to the first software based on the response.

[0232] 4. The cryptographic device according to any one of the foregoing clauses, wherein,

[0233] - The second software is configured to send a message including the authentication tag to the first software via a software interface within the cryptographic device, or

[0234] - The second software is configured to display the authentication tag on the display, and the first authentication is configured to receive the authentication tag from the user through the input interface of the cryptographic device.

[0235] 5. A cryptographic method (500) for secure communication with a server, the method comprising:

[0236] - Executing (510) the first software in the normal mode of the processor system, the processor system being configured with the normal mode and a secure mode, wherein data and code in the secure mode are isolated from those in the normal mode, and the data in the secure mode includes at least a private key and a secret shared with the user, the execution of the first software comprising:

[0237] - Receive an encrypted message (511) from the server, the encrypted message being encrypted using the public key of the cryptographic device corresponding to the private key.

[0238] - Forward the encrypted message (512) to the second software, and

[0239] - Execute the second software (520) in the safe mode, the execution of the second software includes:

[0240] - Decrypt the encrypted message using the private key stored in the data of the security mode (521).

[0241] - Display the shared secret along with the message on the display (522) to indicate to the user that the message is being displayed by software running in the safe mode.

[0242] 6. A cryptographic device configured for secure communication with a server, the device comprising:

[0243] - A communication interface configured to communicate with the server.

[0244] - A processor system configured with a normal mode and a secure mode, wherein data and code in the secure mode are isolated from those in the normal mode, and the data in the secure mode includes at least secrets shared with the user of the device, wherein...

[0245] -Execute the first software in the normal mode, the first software being configured to:

[0246] - Receive a signature message from the server, the signature message being signed using the server's private key.

[0247] - Forward the signed message to the second software.

[0248] - The second software is executed in the safe mode, and the second software is configured to:

[0249] - Use the public key corresponding to the server's private key to verify the signature on the signed message.

[0250] - The shared secret is displayed on the display of the cryptographic device along with the message to indicate to the user that the message is being displayed by software running in the secure mode.

[0251] 7. A cryptographic method for secure communication with a server, the method comprising:

[0252] - Executing the first software in the normal mode of a processor system, the processor system being configured with the normal mode and a secure mode, wherein data and code in the secure mode are isolated from those in the normal mode, and the data in the secure mode includes at least secrets shared with the user, the execution of the first software comprising:

[0253] - Receive a signature message from the server, the signature message being signed using the server's private key.

[0254] - Forward the signed message to the second software, and

[0255] - Execute the second software in the safe mode, wherein executing the second software includes:

[0256] - Use the public key corresponding to the server's private key to verify the signature on the signed message.

[0257] - The shared secret will be displayed on the screen along with the message to indicate to the user that the message is being displayed by software running in the security mode.

[0258] It should be noted that the above embodiments are illustrative and not limiting of the subject matter of this disclosure, and those skilled in the art will be able to devise many alternative embodiments.

[0259] In the claims, any reference numerals placed in parentheses should not be construed as limiting the claims. The use of the verb "comprising" and its variations does not exclude the presence of other elements or steps different from those described in the claims. The words "a" or "an" preceding an element do not exclude the presence of a plurality of such elements. When preceding a list of elements, expressions such as "at least one of..." indicate the selection of all elements or any subset of elements from the list. For example, the expression "at least one of A, B, and C" should be understood to include only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The subject matter of this disclosure can be implemented by hardware comprising several different elements and can be implemented by a suitably programmed computer. In device claims enumerating several parts, several of these parts can be embodied by the same item of hardware. Although specific measures are recited in mutually different dependent claims, this does not indicate that combinations of these measures cannot be advantageously used.

[0260] In the claims, the reference numerals in parentheses refer to reference numerals in the drawings of the illustrative embodiments or to formulas of the embodiments, thus increasing the comprehensibility of the claims. These reference numerals should not be construed as limiting the claims.

Claims

1. A cryptographic device, comprising: A communication interface circuit, wherein the communication interface circuit is arranged to communicate with a server. Processor circuit, The processor circuit has a normal mode and a security mode. When the processor circuit is in the safe mode, data and code are isolated from the normal mode. The data includes at least a secret and a private key corresponding to the public key of the cryptographic device. The secret mentioned herein is shared with the user. Specifically, the first software is executed when the processor circuit is in the normal mode. The first software is configured to receive encrypted messages and encrypted authentication tags from the server. The encrypted message and the encrypted authentication tag are encrypted using the public key of the cryptographic device. The first software is configured to forward the encrypted message and the encrypted authentication tag to the second software. Specifically, the second software is executed when the processor circuit is in the safe mode. The second software is configured to decrypt the encrypted message and the encrypted authentication tag using the private key. The private key is stored in the data under the security mode. The second software is configured to display the shared secret, the message, and a decryption authentication tag to indicate to the user that the message is being displayed by software running in the secure mode. The legacy software is configured to receive the decryption authentication tag from the user through the input interface of the cryptographic device.

2. The cryptographic device according to claim 1, in, The cryptographic device is configured to authenticate with the server. The legacy software is configured to send authentication messages to the server. The authentication message depends on the decryption authentication tag in order to authenticate the cryptographic device to the server.

3. The cryptographic device according to claim 1, in, The encrypted message is received in conjunction with the encrypted authentication tag. The second software is configured to receive a response to the message from the user.

4. The cryptographic device according to claim 1, wherein, The startup code of the cryptographic device is configured to receive the shared secret from the user during the initialization startup sequence.

5. The cryptographic device according to claim 1, in, The display of the cryptographic device operates according to a frame buffer that can be accessed from the normal mode, wherein the display operates according to a frame buffer that can be accessed from the secure mode rather than from the normal mode.

6. The cryptographic device according to claim 1, in, The SMS message includes the encrypted authentication tag. The first software is configured to intercept the SMS message. The first software is configured to forward the message to the second software. The second software is configured to provide the decryption authentication tag to the user.

7. The cryptographic device according to claim 1, in, The second software is configured to generate the public key and the private key. The second software is configured to store the private key in the data of the secure mode. The second software is configured to send the public key to the first software. The first software is configured to send the public key to the server. The first software is configured to display the public key and the shared secret. The public key is displayed in an optically readable format.

8. The cryptographic device according to claim 1, wherein, The first software and / or the second software are configured to receive additional authentication factors from the user before the authentication of the server is completed.

9. The cryptographic device according to claim 1, in, The first software is configured to send transaction requests to the server. The first software is configured to receive the encrypted authentication tag in response to the transaction request.

10. The cryptographic device according to claim 9, wherein, The message depends on the request.

11. The cryptographic device according to claim 1, in, The cryptographic device includes a visual indicator. The visual indicator is configured to indicate whether the content of the display originates from the security mode.

12. The cryptographic device according to claim 1, in, When the message is displayed on the monitor, software running in normal mode cannot overwrite the display of the message.

13. The cryptographic device according to claim 1, wherein, Prevent software running in normal mode from capturing the screen display of the message.

14. The cryptographic device according to claim 1, in, The first software is configured to receive the encrypted message. The encrypted message is signed. The signed message is signed using the server's private key. The second software is configured to use a public key corresponding to the private key of the server to verify the signature on the signed message.

15. A cryptographic method, comprising: The first software is executed in the normal mode of the processor circuit. The processor has a normal mode and a security mode. When the processor circuit is in the safe mode, data and code are isolated from the normal mode. The data includes at least a private key and a secret, wherein the private key corresponds to the public key of the cryptographic device, and the secret is shared with the user. Executing the first software includes: Receive encrypted messages and encrypted authentication tags from the server. The encrypted message and the encrypted authentication tag are encrypted using the public key of the cryptographic device. The encrypted message and the encrypted authentication tag are forwarded to the second software, and Executing the second software in the safe mode includes: The encrypted message and the encrypted authentication tag are decrypted using the private key, wherein the private key is stored in the data of the security mode. Displaying the shared secret, the message, and the decryption authentication tag to indicate to the user that the message is being displayed by software running in the secure mode. The legacy software is configured to receive the authentication tag from the user via an input interface.

16. The method of claim 15, further comprising authenticating the server, in, The legacy software is configured to send authentication messages to the server. The authentication message depends on the decryption authentication tag in order to authenticate the cryptographic device to the server.

17. The method according to claim 15, in, The encrypted message is received in conjunction with the encrypted authentication tag. The second software is configured to receive a response to the message from the user.

18. The method according to claim 15, wherein, The startup code of the cryptographic device is configured to receive the shared secret from the user during the initialization startup sequence.

19. The method according to claim 15, in, The second software is configured to generate the public key and the private key. The second software is configured to store the private key in the data of the secure mode. The second software is configured to send the public key to the first software. In this configuration, the first software is either configured to send the public key to the server, or the first software is configured to display the public key and the shared secret. The public key is displayed in an optically readable format.

20. A computer program stored on a non-transient medium, wherein, The computer program, when run on the processor, performs the method according to claim 15.

Images