Managing access to a secure application in a computer system

Abstract

The invention relates to a method for managing access to a secure application in a secure environment of a computer system comprising the following steps: - upon receipt (502) of a first request from a client application identifying the secure application in an insecure environment, obtaining (506) information uniquely identifying the client application; - generation (530) of a random number in the secure environment; - determination (531) of a unique identifier of the client application based on the generated random number and the information uniquely identifying the client application; - storage of the unique identifier of the client application as metadata of the client application, in the insecure environment.Following this, and upon receipt of a second request to establish a current session, the process includes verifying the unique identifier of the client application prior to establishing the current session. FIG. 5.

Description

Title of the invention: Access management for a secure application in a computer system

[0001] The present invention belongs to the field of computer systems, and in particular to systems comprising a secure environment capable of running at least one secure application, separate from an insecure environment capable of running at least one client application.

[0002] The invention relates in particular to the management of access to secure applications in a secure computer system environment.

[0003] It is known to store sensitive data in secure hardware components of a computer system. This is particularly the case for computer systems based on an ARM™ architecture, such as a system on a chip, also called SoC, for "System on Chip".

[0004] A SoC is a system integrating, on a single chip, a microprocessor, a GPU (Graphical Processing Unit), a DSP (Digital Signal Processing), and other components.

[0005] The ARM SoC, in particular the one based on a Cortex microprocessor, provides for separating a secure environment, called the Trusted Execution Environment, or TEE for "Trusted Execution Environment", also called the "secure world", or "Secure World" in English, from an insecure environment, called the Untrusted Environment, or "Untrusted Environment", also called the "normal world", or "Normal World" in English.

[0006] The TEE environment is intended to protect sensitive data such as private keys or personal information, such as personally identifiable information, or PII, for "Personally Identifiable Information", by limiting their access by client applications of the unsecured environment.

[0007] The TEE environment operating system, called the secure operating system, hosts a set of secure applications, denoted TA, for "Trusted Applications", which have various functions, such as managing secure data storage, storing secure data, calculating secret keys, implementing cryptographic operations, etc.

[0008] Secure applications make these functions available to client applications running in the insecure environment, or normal world. The insecure environment runs on an operating system separate from the secure operating system of the TEE environment. The operating system of The insecure environment can be called a "rich" or "primary" operating system. For example, in the context of a computer system used for automotive applications, the primary operating system might be Android Automotive OS™ or Automotive Grade Linux™.

[0009] Fig. 1 illustrates a computer system 100 according to the prior art.

[0010] Computer system 100 is, for example, based on an ARM architecture of type ARM SoC 101. A secure monitor 102 is capable of providing an interface role between an insecure environment 110 and a secure environment 120.

[0011] The insecure environment 110 is based on a rich operating system, having a rich operating system kernel 111, capable of running a set of client applications, including for example a first client application 112.1 and a second client application 112.2.

[0012] The secure environment 120 is based on a secure operating system, having a secure kernel 121, capable of running a set of secure applications, including for example a first secure application 122.1 and a second secure application 122.2.

[0013] Client applications 112.1 and 112.2 can request services implemented by secure applications 122.1 and 122.2, via secure monitor 102. However, since client applications 112.1 and 112.2 are run in an insecure environment, it is important, even critical, to be able to ensure that the client application wishing to access a service of a secure application is legitimate and is not corrupted by an attacker wishing to access data to which they do not have a legitimate right to access, the data being stored in secure environment 120.

[0014] Indeed, by replacing a legitimate client application with a corrupted client application, an attacker can access data stored in the secure environment 120. Such an attack can cause the leakage of sensitive data, such as PII or the fraudulent use of cryptographic data, for example to authenticate with a third-party server.

[0015] By way of example, a legitimate client application stores its own sensitive data, such as PII information, in secure memory managed by a secure application within the secure environment. If the legitimate client application is replaced by a corrupted client application by an attacker, the corrupted client application can impersonate the legitimate client application when issuing a read request for sensitive data managed by the secure application. In such an example, it is not possible for the secure application to detect that the read request for sensitive data originates from a malicious application. corrupt client.

[0016] Another problem arises when a client application has a global access right to request services from all secure applications in the secure environment 120. In this case, an attacker can, if a client application is corrupted, access all the data in the secure environment 120.

[0017] For example, a secure application can generate cryptographic data in response to a request from a legitimate client application. The cryptographic data can be used by the legitimate client application to establish secure access to a remote third-party server. Another client application, which has been compromised by an attacker, can request the same cryptographic data from the secure application and establish seemingly secure access to the remote server. In this case, neither the secure application nor the remote server can detect that the other client application is not the legitimate client application and that it is compromised.

[0018] Therefore, it is necessary to control the legitimacy of a client application running in a secure environment when it requires access to a service provided by a secure application in the secure environment.

[0019] A first known solution to this problem is described in the document "An Effective Authentication for Client Application Using ARM TrustZone", Hang Jiang et al, December 2017, Lecture Notes in Computer Science, Information Security Practice and Experience, pages 802 to 813. This first solution proposes to authenticate a client application from the insecure environment in order to allow it access to a secure application running in the TEE environment.

[0020] For this purpose, a hash value is calculated from the client application when it is executed, and the resulting hash value is compared to a hash value previously stored in the TEE environment. If the verification of the calculated hash value is positive, a session is authorized to be established between the client application and the required secure application. Otherwise, the session with the secure application is not established.

[0021] If a new client application is installed in the insecure environment, via a software update for example, then a hash value is calculated during the execution of the new client application, and the calculated hash value is stored in the TEE environment for later authentication.

[0022] A second known solution stems from a technical standard developed by Global Platform, intended to assist the development of secure services and systems to ensure the security and confidentiality of sensitive user data. Global Platform defines application programming interface (API) specifications for clients of The TEE environment, for example client applications 112.1 and 112.2 in [Fig. 1], for establishing communication sessions with secure applications 122.1 and 122.2 and with associated services in the secure TEE environment. For example, the publication "TEE Client API Specification", GlobalPlatform Device Technology, Version 1.0, July 2010, defines, in its section 4.4.5 entitled "Session Login Methods", optional methods that can be implemented by the secure operating system 121 to verify the identity of a client application 112.1-112.2 when establishing a session with a secure application 122.1-122.2.

[0023] Some of these methods are based on the provision of identification data, or login, such as data identifying the user under which the client application is run, or the group of users under which the client application is run, or data identifying the client application itself.

[0024] Depending on the data provided for identification, the secure application 122.1-122.2 may decide to grant or refuse access to its services to the client application.

[0025] However, the two aforementioned solutions have the following disadvantages.

[0026] Regarding the first solution mentioned above, although the client application is authenticated by calculating a hash value on the executable source code of the client application, in order to verify that the executable source code is not corrupted by an attacker, it is not permissible to verify that a given client application is indeed authorized to use the services of the secure application for which the establishment of a session is required.

[0027] Since a secure application in the TEE environment can provide services in response to requests from several different client applications in the insecure environment, it is important to verify that a given client application is authorized to access the secure application.

[0028] For example, referring to the example illustrated in [Fig. 1], when the second client application 112.2 requests access to a service of the first secure application 122.1 in the secure environment 120, only the integrity of the source code of the second client application 112.2 is checked according to the first known solution. Thus, there is no provision whatsoever for verifying that the second client application 112.2 is indeed authorized to request a service from the first secure application 122.1.

[0029] Furthermore, in the first known solution, a new client application can be installed during a software update of system 100, and a hash value of the new application is calculated during its execution. During this period, an attacker can install a corrupted client application if the secure update mechanism is compromised. In this case, the first known solution provides for Calculate the hash value for the corrupted client application, which is then considered legitimate for establishing future communication sessions with secure applications. The corrupted client application can thus access private / confidential data stored in the TEE 120 environment.

[0030] Finally, the first known solution requires storing pre-calculated hash values ​​in the TEE environment. This necessitates strict synchronization when storing the pre-calculated hash values ​​for client applications in the TEE environment. If an error occurs during the provisioning or loading of the pre-calculated hash values, future authentications based on these hash values ​​may be flawed.

[0031] Regarding the second known solution, the aforementioned specification document does not mention any standard for verifying the legitimacy of a client application. It is the responsibility, during the implementation of the security of the rich operating system 111, to ensure the maintenance of the security of client applications and the detection of any modification made to a client application.

[0032] An attacker can then carry out the following attack: considering a secure environment 120 using an identification method based on a user ID, a method called "TEEC_LOGIN_USER" in the aforementioned document corresponding to the second solution, a client application indicating the user ID can access the service of a secure application.

[0033] If the secure application determines that the client application requesting the service belongs to the user corresponding to the user ID, then it authorizes access to the service. However, when a client application is compromised by an attacker, it may still retain its association with the user ID, allowing it to access the secure application's service. Therefore, the second known solution poses security problems.

[0034] Furthermore, the aforementioned specification, corresponding to the second known solution, identifies the client application by the user or user group to which it belongs. However, no restrictions are defined in the specification regarding access by another client application, belonging to the same user or user group, to this same secure application. Consequently, within client applications belonging to the same user or user group, there is no separation of access to secure applications.

[0035] For example, referring to [Fig. 1] described above, and considering that the first client application 112.1 and the second application 112.2 belong to the same first user, but that a third client application, not shown in [Fig. 1], belongs to a second user different from the first user, then: - the first client application 112.1 can create and possess crypto- data graphics in a secure storage module of the secure environment 120, via the first secure application 122.1; - the third client application, which does not belong to the first user owning the first client application 112.1, cannot access the cryptographic data stored in the secure storage module; - however, the second client application 112.2 can indeed access the cryptographic data because it belongs to the same user as the first client application 112.1.

[0036] Thus, the first secure application 122.1 has no access control mechanism to prevent the second client application 112.2 from accessing cryptographic data that belongs to the first client application 112.1.

[0037] Consequently, none of the known solutions allows secure management of access of a client application to a service of a secure application in a secure environment, such as the TEE environment, ensuring that each client application, and only it, has access to sensitive data such as PII data or cryptographic data for example.

[0038] There is therefore a need to improve the security associated with the access of a client application to the service of a secure application running in a secure environment, such as the TEE environment for example.

[0039] The present invention improves the situation.

[0040] To this end, a first aspect of the invention relates to a method for managing access to a secure application in a secure environment of a computer system, for establishing a current communication session between a client application in an unsecure environment of the computer system, and the secure application, the method comprising the following steps: - upon receipt of a first request from the client application, the first request identifying the secure application from which verification is required, obtaining information uniquely identifying the client application in the insecure environment; - generation of a random number in the secure environment; - determination of a unique identifier for the client application, by the secure application, based on the generated random number and the information uniquely identifying the client application in the non-secure environment; - storing the unique identifier of the client application as client application metadata, in the insecure environment; - following the storage of the unique identifier in the insecure environment, and the receipt of a second request to establish a current session between client application and secure application, verification of the unique identifier of the client application prior to establishing the current communication session between the client application and the secure application.

[0041] Thus, the invention proposes the creation of a unique identifier for the client application, embodying a unique link between the client application and the secure application. The uniqueness of this link is due to the generation of a random number within the secure environment. This unique identifier is then used as verification data for establishing a current communication session between the client application and the secure application. Consequently, a given client application cannot access data resulting from the implementation of a service between a secure application and another client application. Furthermore, the proposed solution does not require prior storage of metadata relating to a client application in the secure environment. This avoids the need to update the secure environment when installing a new client application in the non-secure environment.

[0042] According to some embodiments, the information uniquely identifying the client application in the insecure environment can be a path to the client application in a file system of the insecure environment.

[0043] Such a path in a file system does allow unique identification in an insecure environment, and is verifiable by a trusted third-party entity running on a kernel of the insecure environment.

[0044] According to embodiments, obtaining the information uniquely identifying the client application and storing the unique identifier in the unsecure environment can be implemented by a trust gateway of the unsecure environment, the method including a prior secure startup phase of the computer system during which the trust gateway and each secure application of the secure environment are signed by a set of keys from a root of trust.

[0045] Thus, the entities implementing the invention communicate securely and are mutually authenticated before the implementation of the invention, which strengthens the security associated with access management according to the invention.

[0046] According to embodiments, a client application data structure may include binary source code, a list of at least one legitimate secure application for the client application and a signature obtained from the binary source code and said list, and the method may include, prior to the generation of the random number, a check that the secure application identified in the first query is part of the list of at least one legitimate secure application of the client application data structure.

[0047] Thus, prior verification of the legitimacy of access to the secure application can be implemented. Furthermore, the signature makes it possible to verify that the list of at least one legitimate secure application has not been modified by the client application. The integrity of the list is therefore ensured.

[0048] According to some embodiments, the unique identifier of the client application can be stored as metadata which is not modifiable by said client application.

[0049] Thus, a corrupted client application is unable to modify the unique identifier of the client application.

[0050] In addition, the unique identifier of the client application can be stored as an extended attribute of a binary source code of the client application.

[0051] The extended attribute is a feature offered by some file systems. Moreover, such a feature can prevent the client application from being able to modify the extended attribute, as explained in the detailed description that follows.

[0052] According to embodiments, the unique identifier of the client application can be stored as metadata in association with an identifier of the secure application.

[0053] Thus, unique links can be created, securely, between the client application and a plurality of secure applications in the secure environment.

[0054] According to embodiments, following the determination of the unique identifier of the client application, the method may further include storing, in the secure environment, an association between the generated random number and a hash value obtained from the information uniquely identifying the client application in the insecure environment, and the verification of the unique identifier of the client application prior to establishing the current communication session between the client application and the secure application may include the following steps: - obtaining a current hash value of the information uniquely identifying the secure application, via a trusted gateway from the insecure environment; - transmission, via the trusted gateway, of the current hash value and the unique identifier of the client application, to the secure application; - obtaining, by the secure application, the random number stored in association with the current hash value in the secure environment; - verification that the unique identifier of the client application received from the trusted gateway was obtained from the random number obtained and from the current hash value.

[0055] Thus, it is permissible to ensure that the entity with the unique identifier is indeed the client application for which the previous steps were implemented. The establishment of the current communication session is thus conditional upon such prior verification, which strengthens the security associated with access to the secure application.

[0056] A second aspect of the invention relates to a computer program comprising instructions for implementing the method according to the first aspect of the invention, when these instructions are executed by a processor.

[0057] A third aspect of the invention relates to a computer system comprising an insecure environment capable of running at least one client application, and a secure environment capable of running at least one secure application, in which: - the insecure environment includes a rich kernel capable of, upon receiving a first request from a client application, the first request identifying a secure application from which verification is required, obtaining information uniquely identifying the client application in the insecure environment; - the secure application is capable of generating a random number in the secure environment, and of determining a unique identifier of the client application based on the generated random number and the information uniquely identifying the client application in the non-secure environment; - The rich kernel is configured to store the unique identifier of the client application as client application metadata in the insecure environment; and - following the storage of the unique identifier in the insecure environment, and a reception by the rich kernel of a second request to establish a current session between the client application and the secure application, the secure application is able to verify the unique identifier of the client application prior to the establishment of the current communication session between the client application and the secure application.

[0058] Other features and advantages of the invention will become apparent from an examination of the detailed description below, and the accompanying drawings in which:

[0059] [Fig-1] illustrates a computer system comprising a secure environment and a unsafe environment, according to prior art;

[0060] [Fig.2] illustrates a computer system comprising a secure environment and a unsecure environment, according to embodiments of the invention;

[0061] [Fig.3] illustrates a data structure of a client application, in a system format according to embodiments of the invention;

[0062] [Fig.4] illustrates the steps of a preliminary phase of data structure creation according to [Fig.3], in a method of managing access to a secure application according to embodiments of the invention;

[0063] [Fig. 5] illustrates the steps of a verification phase of a client application with of a secure application, of a method for managing access to the secure application according to embodiments of the invention;

[0064] [Fig. 6] illustrates the steps of a phase of assigning a unique identifier to a client application, of a process for managing access to a secure application according to embodiments of the invention

[0065] [Fig.7] illustrates the steps of a phase of establishing a current session of a method for managing access to a secure application according to embodiments of the invention.

[0066] Fig. 1 illustrates a computer system 200 comprising a secure environment 220 and an insecure environment 210, according to embodiments of the invention.

[0067] The computer system 200 is, for example, based on an ARM SoC ARM 201 architecture. A secure monitor 202 is capable of providing an interface role between the insecure environment 210 and the secure environment 220. The secure monitor 202 is a secure firmware, for example, an ARM secure firmware, running on the ARM SoC 201 hardware components.

[0068] The insecure environment 210 is based on a rich operating system, having a rich operating system kernel 211, such as a Linux™ kernel for example, capable of running a set of client applications, including for example a client application 212, and possibly including other client applications not shown in [Fig.2].

[0069] The secure environment 220 is based on a secure operating system, having a secure kernel 221, capable of running a set of secure applications, including for example a secure application 222, and which may include other secure applications not shown in [Fig.2].

[0070] The insecure environment 210 runs on an operating system separate from the secure operating system of the secure environment 220, which may be a TEE environment. The operating system of the insecure environment may be called the "rich" or "primary" operating system. For example, in the context of a computer system used for automotive applications, the primary operating system may be Android Automotive OS™ or Automotive Grade Linux™.

[0071] The unsecure environment 210 can be implemented by a first set of hardware and software components, of the ARM SoC 201 system on chip and the unsecure environment 220 can be implemented by a second set of hardware and software components, of the ARM SoC 201 system on chip.

[0072] No restrictions are attached to the hardware and software components of the first and second assemblies.

[0073] The client application 212 may require services implemented by the secure application 222, via the secure monitor 202, as described below. Within the framework of such secure services, sensitive data specific to the client application 212 may be stored in a secure database 223 of the secure environment 220, access to which is managed by the secure application 222. Sensitive data may be any data generated or used by the client application 212, such as private keys or personal information, such as personally identifiable information (PII).

[0074] As explained previously, since the client application 212 is run in an insecure environment 210, it is preferable to be able to ensure that the client application wishing to access a service of a secure application is legitimate, and is not corrupted by an attacker wishing to access sensitive data which he does not legitimately have the right to access and which is stored in the secure database 223.

[0075] According to embodiments of the invention, the rich kernel 211 implements a gateway 213, referred to as the trust gateway, between the insecure environment 210, comprising the client application 212, and the secure environment 220. The functionalities implemented by the trust gateway 213 will be better understood in the following. The trust gateway can be considered as an API for accessing the trusted zone constituted by the secure environment 220.

[0076] The computer system 200 according to the invention can be integrated into a motor vehicle for the execution of a client application 212 having a function within the motor vehicle. No restrictions are attached to the function, or functions, performed by the client application 212.

[0077] The computer system 200 can initiate a secure boot, which is a known boot procedure, and which allows the creation of a secure execution platform for automotive software. The secure boot procedure ensures that the software components involved in the boot process, such as the secure firmware 202, the secure kernel 221 and the secure application 222, the rich kernel 211 and a boot loader unit, are cryptographically signed using a set of keys that are linked by a root of trust, called the "root of trust," of the hardware system-on-chip 201. A root of trust is a permanent trusted resource within a cryptographic system.

[0078] The software components initialized during the secure boot process, including the rich kernel 211, are thus checked one after the other. However, the user-space software components, or insecure environment 210, in The components on which client application 212 is executed are not part of the secure boot chain and therefore cannot be considered reliable or trustworthy. However, the invention overcomes this limitation.

[0079] Fig. 3 illustrates a data structure 300 of the client application file 212, in a computer system 200 according to embodiments of the invention.

[0080] Data structure 300 is an image of the binary file, or executable file, of client application 212.

[0081] The data structure comprises the binary source code 301, or executable, of the client application 212, and further comprises additional sections according to the invention.

[0082] A first additional section may be a hash value 302 obtained from a hash function applied to the binary source code 301 of the client application 212, with no restrictions being applied to the hash function considered.

[0083] A second additional section 303 may include at least one secure application identifier, for example in the form of a list of secure application identifiers, each secure application identifier identifying a secure application for which the client application 212 is authorized to request a service. The list may thus include a list of secure application identifiers corresponding to a subset of the secure applications hosted by the secure environment 220.

[0084] In the simplified example of [Fig.2], the client application 212 requires access to the service of the secure application 222 to which it has legitimate access, and the file corresponding to the data structure 300 therefore includes an identifier of the secure application 222 in the second additional section.

[0085] No restrictions are attached to the format of the secure application identifier 222 stored in the second additional section 303, which can be any identifier capable of uniquely identifying the secure application 222 in the secure environment 220. For example, the secure application identifier 222 can be a universally unique identifier, also called a UUID, for "Universally Unique Identifier", which is a 128-bit identifier defined by the RFC 4122 standard.

[0086] A third additional section 304 may include a signed hash value, obtained by signing a value obtained from the binary source code 301 and the list of at least one secure application identifier 303. For example, an "exclusive OR" or XOR function is applied to the hash value 302 of the binary source code 301 and to the list 303.

[0087] The output of the XOR operation can be passed to a cryptographically secure hash function to determine a second hash value, also called "digital footprint" or "message digest" in English.

[0088] The digital fingerprint is signed to obtain the signed hash value, using a private key from an asymmetric key pair. The secure environment 220 has the associated public key, and is thus able to verify the signed hash value.

[0089] Figure 4 presents steps 400 to 408 of a preliminary phase of a method for managing access to a secure application, according to embodiments of the invention.

[0090] The preliminary phase can be implemented before the current phases described below and aims to determine and store the data structure 300 of each client application 212 in the insecure environment 210. No restrictions are attached to the hardware or software entity responsible for constructing the data structure 300 for each client application. The data structure can, in particular, be constructed following the development of the application's source code, specifically during the compilation of the client application 212's source code.

[0091] The preliminary phase can thus be implemented by the entity in charge of compiling the source code of client application 212.

[0092] At step 400, the source code of client application 212 is obtained.

[0093] At a 401 step, the source code of client application 212 is compiled to obtain the binary source code of client application 212.

[0094] At a step 402, a first hash value is calculated from the binary source code of the client application 212.

[0095] At a step 403, implemented in parallel with step 402, or implemented before or after step 403, the list of at least one secure application 222 for which the client application 212 is authorized to request a service, is obtained.

[0096] At a 404 step, the XOR function is applied to the first hash value and to the list of at least one 222 secure application, to obtain a digital fingerprint.

[0097] At a step 405, the cryptographically secured hash function is applied to the digital fingerprint to obtain the second hash value.

[0098] At a step 406, implemented in parallel with step 405, or implemented before or after step 405, the private key of the aforementioned asymmetric key pair is obtained. As previously stated, the public key is then made accessible in the secure environment 220, for example, stored in a memory location within the secure environment 220.

[0099] At a step 407, the second hash value is signed from the private key of the asymmetric key pair.

[0100] At step 408, the first hash value is added to the binary source code of The client application 212 is in the first additional section 302, the list of at least one secure application 222 is added in the second additional section 303 and the second signed hash value is added in the third additional section 304. The data structure 300 is thus constructed for the client application 212.

[0101] At a step 409, the data structure 300 is stored in the insecure environment 110, in association with a file system path, from which the data structure 300 is accessible by the rich kernel 211.

[0102] Figure 5 shows the steps of a verification phase of a client application, the verification phase being part of a process for managing access to a secure application, according to embodiments of the invention.

[0103] The verification phase aims to verify that a client application 212, having the data structure 300 described above, is legitimate to access the secure application 222 of the secure environment 220 and aims to create an identifier materializing a unique link between the secure application and the client application.

[0104] The verification phase can be implemented in the following situation: - the rich kernel 211, including the trust gateway 213, the secure kernel 221 and the secure applications it supports, including the secure application 222, as well as the firmware 202, were signed and verified during a secure boot procedure, described previously; - the public key of the asymmetric key pair comprising the private key with which the third additional section 304 of the data structure 300 of the client application 212 is obtained, is stored in the secure environment 220, and made available to the secure application 222, for example in a memory of the secure environment 220; - The trusted gateway 213 is able to add an attribute associated with a client application 212 in the insecure environment 210, without that client application 212 being allowed to modify the attribute added by the gateway 213. Such an attribute can be an extended attribute, which can be associated with the binary source code 301 of the client application. For example, a POSIX feature of type CAP_SYS_ADMIN is disabled, so as to prevent the client application 212 from modifying the extended attribute that is assigned to its binary source code 301. POSIX is a set of standards from the IEEE, for "Institute of Electrical and Electronics Engineers"; - The file system of the insecure environment 210 accepts the addition of attributes to client applications, such as the aforementioned extended attributes.

[0105] At step 501 of the verification phase, client application 212 is loaded into volatile memory from the unsecure environment 210 is accessed by the rich kernel 211 and then executed. In particular, the executable binary source code 301 of the client application 212 is executed.

[0106] At a step 502, following its execution, the client application 212 transmits a request including a trusted application identifier, such as the UIDD identifier of the trusted application 222 with which the client application 212 requires verification in order to subsequently access a service of the trusted application 222, to the trusted gateway 213.

[0107] At a step 503, the trust gateway 213 receives the request including the identifier of the trusted application 222.

[0108] At a step 504, the trust gateway 213 transmits the identifier of the secure application 212 to the secure kernel 221, for loading of the secure application 212 corresponding to the identifier received.

[0109] At a 505 step, the trust gateway 213 can confirm the initiation of the verification phase with the client application 212, and generate a session identifier, or "session handle" in English.

[0110] At a step 506, the trust gateway 213 obtains information that uniquely identifies, in the rich environment 210 or in absolute terms, the data structure 300 of the client application 212 that issued the request. Such information may be a path in the file system of the rich environment 210, or alternatively, an inode number. In what follows, it is considered, for illustrative purposes only, that the information uniquely identifying the file of the client application 212 is the path in the file system of the insecure environment 210. Thus, at step 506, the trust gateway 213 obtains the file system path identifying the source binary code of the client application 212, from which the client application 212 is loaded and executed.

[0111] At a step 507, the trust gateway 213 calculates a first running hash value denoted HCal, which is a hash value of the binary source code 301 of the client application 212 corresponding to the file system path obtained in the previous step.

[0112] At a step 508, the trust gateway calculates a second current hash value, which is a hash value of the information uniquely identifying the client application 212 in the insecure environment 210, i.e., in the example considered, a hash value of the file system path to the source binary code 301 of the client application 212, obtained at step 506.

[0113] At step 509, the trust gateway 213 extracts the following information from the data structure 300 which it accesses from the file system path obtained at step 506: - the hash value, denoted HCa, which is stored in the first additional segment 302 of the data structure 300 of the client application 212, obtained by hashing the binary source code 301; - list 303 stored in the second additional segment of data structure 300 of client application 212; - the signed hash value 304 stored in the third additional segment of the data structure 300 of the client application 212.

[0114] Note that steps 506 to 509 can be implemented in parallel or sequentially but in a different order than that shown in [Fig.5].

[0115] At a step 510, the trust gateway 213 compares the first current hash value HCal and the hash value HCa stored in the first additional segment 302 of the data structure 300.

[0116] If the two hash values ​​HCal and HCA are different, the trust gateway 213 interrupts the verification phase and returns an error message to the client application 212 at a step 511. Thus, the comparison at step 510 ensures that the binary source code 301 has not been modified after the determination and storage of the data structure 300.

[0117] If the two hash values ​​HCal and HCa are identical, the trusted gateway 213 transmits the following information, at step 512, to the secure kernel 221: - the hash value HCal or HCa, which are identical, which corresponds to the hash value of the binary source code of client application 212; - list 303 including at least one secure application identifier, including the secure application identifier 222 which the client application 212 wishes to access; - the signed hash value 304 obtained from the data structure 300; - the second current hash value, which is the hash value of the information uniquely identifying client application 212 in the insecure environment 210, i.e., in the example considered, the hash value of the file system path to the source binary code 301 of client application 212.

[0118] At a step 520, the secure kernel 221 transmits the information received at step 511 to the secure application 222, which was previously executed following step 504.

[0119] At a step 521, the secure application 222 obtains the public key available in the secure environment 120, associated with the private key from which the signed hash value 304 was obtained.

[0120] At a step 522, the secure application 222 verifies the signature of the signed hash value 304 received at step 520, from the public key obtained at step 521.

[0121] If the verification is positive following step 522, that is, if the received signed hash value 304 has indeed been signed with a private key corresponding to the public key obtained in step 521, the process proceeds to step 526 described below.

[0122] Otherwise, in the event of a negative check at step 522, an error message is sent to the trust gateway 213, via the secure kernel 221, at a step 523. The trust gateway 213 can then forward the error message to the client application 212 and the check phase is interrupted.

[0123] Step 522 thus makes it possible to verify that the signed hash value does indeed come from a trusted entity.

[0124] In parallel with steps 521 and 522, or alternatively before or after steps 521 and 522, the secure application 222 calculates a third current hash value, or current fingerprint, at steps 524 and 525, for comparison with the signed hash value 304 received at step 520. The calculation of the current signed hash value may include: - the application, at step 524, of an XOR operation to the hash value HCa or Hcal and to list 303, both received at step 520; - the calculation, at a step 525, of the third current hash value, also called the current digital fingerprint, by applying a hash function to the result of the XOR operation.

[0125] At a step 526, the secure application 222 compares the third current hash value obtained at step 525 with the signed hash value 304 received at step 520 and whose signature was verified at step 522.

[0126] In the event of a negative comparison, i.e., if the third current hash value obtained at step 525 does not correspond to the signed hash value 304 received at step 520, then the secure application 222 can transmit an error message to the trust gateway 213, via the secure kernel 221, at a step 527. The trust gateway 213 can transmit the error message to the client application 212 and the verification phase is interrupted.

[0127] On the contrary, in the event of a positive comparison at step 526, the secure application 222 checks, at a step 528, that its own secure application identifier is present in the list 303 received at step 520.

[0128] In case of a negative check at step 528, if the identifier of the secure application 222 is absent from the list 303 received at step 520, then the secure application 222 transmits an error message to the trust gateway 213, via the secure kernel 221, at a step 528.

[0129] On the contrary, in the event of a positive check, which is the case in the example considered here in which the client application 212 legitimately requests access to the secure application 222, the secure application 222 generates a random number at step 529. For this purpose, the secure application 222 can use a cryptographically secured random number generator in the secure environment 220.

[0130] At a step 530, the secure application 222 can generate a unique identifier for the client application 212, from the random number generated in step 529 and from the second current hash value, which, as a reminder, is a hash value of the information uniquely identifying the client application 212 in the insecure environment 210. For example, the unique identifier for the client application 212 can be obtained by applying an exclusive OR, or XOR, operation to the second current hash value and the generated random number. The unique identifier for the client application 212 thus generated is denoted CA ID in what follows.

[0131] At a step 531, the secure application 222 stores the generated random number in association with the second current hash value, which is the hash value of the information uniquely identifying the client application 212 in the insecure environment 210. The storage can be implemented in the secure database 223 of the secure environment 220 for example.

[0132] At a step 532, the secure application 222 transmits to the trust platform 213, the CA ID generated at step 530, can confirm the verification of the client application 212 by the secure application 222 as well as the session ID, or “session handle”.

[0133] [Fig.6] shows the steps of a phase of assigning the unique identifier to the client application 212, following the verification phase of [Fig.5], according to embodiments of the invention.

[0134] The allocation phase can be implemented by the previously described trust gateway 213.

[0135] At a step 600, the trust gateway 213 receives the information transmitted by the secure application at step 532 described previously, namely the CA ID, the client application verification confirmation 212 and the session ID.

[0136] At step 601, the trust gateway 213 associates a pair comprising the unique identifier of the secure application 222 and the CA ID, as a key-value pair for example, with the data structure 300 of the client application 212. For this purpose, the key-value pair can be inserted as an extended attribute of the inode of the binary source code 301 of the client application 212. As previously described, the extended attribute is a feature permitted in file systems such as EXT3 and EXT4, which are commonly supported by Linux-based operating systems, particularly in automotive applications. The extended attribute functionality allows for the secure storage of file metadata. In the present invention, the stored metadata is the aforementioned pair, comprising the unique identifier of the secure application 222 and the generated CA ID.

[0137] It should be noted that the verification phase described with reference to [Fig. 5] can be iterated for several secure applications that the client application 212 legitimately requests access to. In this case, several key-value pairs are obtained, each pair identifying as the key the unique identifier of one of the secure applications with which the verification phase was implemented, and each pair having a CA ID value different from the values ​​of the other key-value pairs: thus, a unique CA ID is generated for each verification with a given secure application. If the client application 212 requests a session with a first secure application during a first verification phase, a first unique CA ID is obtained and then stored in a first key-value pair in association with the unique identifier of the first secure application.Next, if the same 212 client application requires a session with a second trusted application during a second verification phase, a second unique CA ID is obtained and then stored in a second key-value pair in association with the unique identifier of the second trusted application. Thus, multiple key-value pairs can be stored as extended attributes of the 212 client application's 301 binary source code.

[0138] According to the invention, it is advantageous that the client application 212 is unable to modify the extended attribute assigned to it by the trust gateway 213. Thus, a corrupted client application 212 cannot modify the stored key-value pair. As previously mentioned, the POSIX capability CAP_SYS_ADMIN can be disabled for this purpose, so that a corrupted client application cannot modify the extended attributes.

[0139] At a step 602, the trust gateway 213 can transmit the verification confirmation and the session identifier to the client application 212.

[0140] The invention thus makes it possible to create a unique, and unmodifiable, link between a client application and a secure application with which it requires establishing a session.

[0141] Following the creation of such a link, the client application 212 can then establish further sessions, subsequently, between the client application 212 and the secure application 222, as described with reference to [Fig.7].

[0142] [Fig.7] presents the steps of a phase of establishing a current session between a secure application and a client application, following the assignment phase presented with reference to [Fig.6], according to embodiments of the invention.

[0143] At step 701, the client application 212 is loaded into volatile memory of the insecure environment 210 by the rich kernel 211 and then executed. In particular, the executable binary source code 301 of the client application 212 is executed.

[0144] At a step 702, following its execution, the client application 212 transmits a request including a trusted application identifier, such as the UIDD identifier of the trusted application 222 with which the client application 212 requests the establishment of a session to access a service of the trusted application 222, to the trusted gateway 213.

[0145] At a step 703, the trust gateway 213 receives the request including the identifier of the secure application 222.

[0146] At a step 704, the trust gateway 213 transmits the identifier of the secure application 212 to the secure kernel 221, for loading of the secure application 212 corresponding to the identifier received.

[0147] At a step 705, the trust gateway 213 can confirm the initiation of the verification phase with the client application 212.

[0148] At a step 706, the trust gateway 213 obtains the information that uniquely identifies, either in the rich environment 210 or absolutely, the data structure 300 of the client application 212 that issued the request. As described previously, such information can be the path in the file system of the rich environment 210, or alternatively, the inode number. In the example considered, the information uniquely identifying the client application 212's file is the path in the file system. Thus, at step 706, the trust gateway 213 obtains the file system path identifying the source binary code of the client application 212, from which the client application 212 is loaded and executed.

[0149] Steps 701 to 706 are thus identical to steps 501 to 506 previously described, except that steps 701 to 706 are implemented after the verification phase comprising steps 501 to 532.

[0150] At a step 707, the trust gateway 213 verifies that at least one key-value pair is contained in the extended attributes of the binary source code 301 corresponding to the information uniquely identifying the client application 212, obtained in the previous step.

[0151] If the binary source code 301 of the client application 212 does not include any extended attribute, or if the extended attribute does not include any key-value pair, then the verification phase described above is implemented from step 507.

[0152] If the binary source code 301 of the client application 212 includes at least one extended attribute corresponding to a key-value pair, then the trust gateway 213 checks, at a step 708, whether a key-value pair of the extended attributes includes the trusted application identifier 222 received at step 703, as the key.

[0153] In the event of a negative check, i.e., if no key-value pair of the extended attributes of client application 212 includes the identifier of the secure application 222 received at step 703, as a key, then the verification phase described above is implemented from step 507.

[0154] On the contrary, in the event of a positive check in step 708, the trust gateway 213 obtains the unique CA ID paired with the identifier of the secure application 222 in the extended attributes, and calculates, in a step 709, a current hash value of the information uniquely identifying the client application 212 in the insecure environment 210, that is, in the example considered, a hash value of the file system path to the source binary code 301 of the client application 212, obtained in step 706.

[0155] Note that the positive verification of step 708 indicates that the client application 212 has been previously verified by the secure application 222 with which it requires the establishment of a current session.

[0156] At step 710, the trusted gateway 213 transmits the following information to the secure kernel 221: - the secure application identifier 222 obtained from the request in step 703; - the current hash value determined in step 709; - the unique CA ID paired with the secure application ID 222 in the extended attributes of the client application 212, obtained in step 709.

[0157] At a step 720, the secure kernel 221 transmits the information received at step 710 of the trust gateway 213, to the secure application 222 corresponding to the secure application identifier received in the information.

[0158] At a step 721, the secure application 222 checks whether the secure application identifier included in the information received at step 720 matches its own identifier.

[0159] In the event of a negative check, i.e., if the received trusted application identifier does not match the identifier of trusted application 222, then trusted application 222 sends an error message, at step 722, to trusted gateway 213, via secure kernel 221, and the current session establishment phase is interrupted, without a current session being established. Trusted gateway 213 can forward the error message to client application 212.

[0160] Conversely, if the check is successful in step 721, the secure application 222 checks, in step 723, whether the current hash value included in the information received in step 720 is stored in the secure database 223 in association with a random number. As a reminder, the current hash value included in the information received in step 720 is the hash value determined in step 709 from the information uniquely identifying the client application 212 in the insecure environment 210; that is, in the example considered, a hash value of the file system path to the binary source code 301 of client application 212, obtained at step 706.

[0161] In the event of a negative check at step 723, i.e., if the secure application 222 determines that the secure database 223 does not contain the current hash value received at step 720, the secure application 222 sends an error message, at a later step 724, to the trust gateway 213, via the secure kernel 221, and the current session establishment phase is interrupted, without a current session being established. The trust gateway 213 can forward the error message to the client application 212.

[0162] Conversely, if the check is successful in step 723, the secure application 222 obtains from the secure database 223 the random number associated with the current hash value and verifies that the unique CA ID included in the information received in step 720 was indeed obtained from the current hash value and the obtained random number. To this end, the secure application 222 can perform an "exclusive OR" (XOR) operation on the obtained random number and the unique CA ID received in step 720, and the result of the operation is compared with the current hash value included in the information received in step 720. If the result of the operation is equal to the current hash value, the secure application 222 determines that the unique CA ID included in the information received in step 720 was indeed obtained from the current hash value and the obtained random number.

[0163] Otherwise, the secure application 222 determines that the unique identity CA ID included in the information received at step 720 was not obtained from the current hash value and the obtained random number, and an error message is generated at step 727 and transmitted to the trust gateway 213. The current session establishment phase is interrupted without a current session having been established.

[0164] If the secure application 222 determines at step 726 that the unique CA ID included in the information received at step 720 was indeed obtained from the current hash value and the obtained random number, then the secure application 222 validates the session establishment with the client application 212, which is considered legitimate, and sends a session establishment confirmation message to the trusted gateway 213 at a step 728.

[0165] The confirmation message may include: - a current session identifier generated by the secure application 222 and the secure kernel 221; - a confirmation status of verification that the client application 212 is legitimate for establishing the current session with the secure application 222.

[0166] At step 730, the trust gateway 213 receives the confirmation message.

[0167] At a step 731, the trust gateway 213 transmits the current session identifier to the client application 212, and the current session is established between the client application 212 and the secure application 222.

[0168] Thus, the invention advantageously allows: - to ensure the integrity of the binary source code 301 and the metadata of the client application 212 which requires the establishment of a current session with a secure application 222; - to ensure the establishment of unique links between secure applications and client applications, so that a given client application cannot access data resulting from the implementation of service between a secure application and another client application.

[0169] Furthermore, the proposed solution does not require prior storage of metadata relating to a client application in the secure environment 220. This avoids an update of the secure environment 220 when installing a new client application in the insecure environment 210.

[0170] The present invention is not limited to the embodiments described above by way of example; it extends to other variants.

Claims

Demands

1. A method for managing access to a secure application (222) in a secure environment (220) of a computer system (200), for establishing a current communication session between a client application (212) in an insecure environment (210) of the computer system, and the secure application, the method comprising the following steps: - upon receiving (502) a first request from the client application, the first request identifying the secure application from which verification is required, obtaining (506) information uniquely identifying the client application in the insecure environment; - generating (530) a random number in the secure environment; - determining (531) a unique identifier of the client application, by the secure application, based on the generated random number and the information uniquely identifying the client application in the insecure environment;- storage (601) of the unique identifier of the client application as metadata of the client application, in the insecure environment; - following the storage of the unique identifier in the insecure environment, and a reception (702) of a second request to establish a current session between the client application and the secure application, verification (703-731) of the unique identifier of the client application prior to the establishment of the current communication session between the client application and the secure application.;

2. A method according to claim 1, wherein the information uniquely identifying the client application (212) in the insecure environment (222) is a path to the client application in a file system of the insecure environment.

3. A method according to any one of the preceding claims, wherein obtaining (506) the information uniquely identifying the client application and storing (601) the unique identifier in the insecure environment are implemented by a trusted gateway (213) of the insecure environment (210), the method comprising a preliminary secure system startup phase in- formal (200) during which the trusted gateway and each secure application (222) in the secure environment are signed by a set of keys from a trusted root.

4. A method according to any one of the preceding claims, wherein a data structure (300) of the client application (212) comprises binary source code (301), a list (303) of at least one legitimate secure application for the client application, and a signature (304) obtained from the binary source code and said list, and wherein, prior to the generation (530) of the random number, the method includes a check (528) that the secure application identified in the first query is part of the list of at least one legitimate secure application in the data structure of the client application.

5. A method according to any one of the preceding claims, wherein the unique identifier of the client application (212) is stored as metadata which is not modifiable by said client application.

6. A method according to claim 5, wherein the unique identifier of the client application (212) is stored as an extended attribute of a binary source code (301) of the client application.

7. A method according to any one of the preceding claims, wherein the unique identifier of the client application (212) is stored as metadata in association with an identifier of the secure application (222).

8. A method according to any one of the preceding claims, wherein, following the determination (531) of the unique identifier of the client application, the method further comprises storing (532), in the secure environment (220), an association between the generated random number and a hash value obtained from the information uniquely identifying the client application in the insecure environment, and wherein the verification (703-731) of the unique identifier of the client application prior to establishing the current communication session between the client application (212) and the secure application comprises the following steps: - obtaining (709) a current hash value of the information uniquely identifying the secure application, by a trusted gateway (713) of the insecure environment;- transmission (710), via the trusted gateway, of the current hash value and the unique identifier of the client application, to the secure application; - obtaining (723), by the secure application, the random number stored in association with the current hash value in the secure environment; - verification (726) that the unique identifier of the client application received from the trusted gateway was obtained from the obtained random number and from the current hash value.

9. Computer program comprising instructions for carrying out the method according to any one of the preceding claims, when such instructions are executed by a processor (201).

10. A computer system (200) comprising an insecure environment (210) capable of running at least one client application (212), and a secure environment (220) capable of running at least one secure application (222), in which: - the insecure environment includes a rich kernel (211) capable of, upon receiving a first request from a client application, the first request identifying a secure application from which verification is required, obtaining information uniquely identifying the client application in the insecure environment; - the secure application is capable of generating a random number in the secure environment, and of determining a unique identifier of the client application based on the generated random number and the information uniquely identifying the client application in the insecure environment; - The rich kernel is configured to store the unique identifier of the client application as client application metadata in the insecure environment; and - following the storage of the unique identifier in the insecure environment, and a reception by the rich kernel of a second request to establish a current session between the client application and the secure application, the secure application is able to verify the unique identifier of the client application prior to the establishment of the current communication session between the client application and the secure application.

Images