Managing access to a secure application in a computer system

Abstract

The invention relates to a method for managing access to a secure application of 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 of a non-secure 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 as a function of 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 non-secure environment.Following this, and upon receipt of a second request to establish a current session, the method comprises verifying the unique identifier of the client application prior to establishing the current session. FIG. 5.

Description

Title of the invention: Managing access to a secure application in a computer system

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

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

[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] An SoC is a system integrating, on a single chip, a microprocessor, a GPU (Graphical Processing Unit) graphics processor, a digital signal processor, DSP (Digital Signal Processing) in English, as well as other components.

[0005] The ARM SoC, in particular that based on a Cortex microprocessor, plans to separate a secure environment, called a trusted execution environment, or TEE for "Trusted Execution Environment", also called a "secure world", or "Secure World" in English, from a non-secure environment, called a non-reliable environment, or "Untrusted Environment", also called a "normal world", or "Normal World" in English.

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

[0007] The operating system of the TEE environment, called the secure operating system, hosts a set of secure applications, noted TA, for "Trusted Applications" in English, which have various functions, such as the management of secure data storage, the storage of secure data, the calculation of secret keys, the implementation of cryptographic operations, etc.

[0008] Secure applications make these functions available to client applications running in the unsecured, or normal, environment. The untrusted environment runs on a separate operating system from the secure operating system of the TEE environment. The operating system of The unsecured environment may be referred to as the "rich" or "core" operating system. For example, in the context of a computer system used for automotive applications, the core operating system may be Android Automotive OS™, or Automotive Grade Linux™.

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

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

[0011] The unsecured environment 110 is based on a rich operating system, having a rich operating system kernel 111, capable of executing a set of client applications, comprising 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 executing a set of secure applications, comprising for example a first secure application 122.1 and a second secure application 122.2.

[0013] The client applications 112.1 and 112.2 can request services implemented by the secure applications 122.1 and 122.2, via the secure monitor 102. However, since the client applications 112.1 and 112.2 are executed in an unsecured 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 he does not legitimately have the right to access, the data being stored in the 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] For example, a legitimate client application stores sensitive data specific to it, such as PII information, in secure memory managed by a secure application in 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 request to read the sensitive data managed by the secure application. In such an example, it is not possible for the secure application to detect that the request to read the sensitive data comes from an application corrupt customer.

[0016] Another problem arises when a client application has a global access right to request services from all the secure applications in the secure environment 120. An attacker can in this case, in the event of corruption of a client application, access all the data in the secure environment 120.

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

[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 of 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 Practive and Experience, pages 802 to 813. This first solution proposes to authenticate a client application of the non-secure environment in order to allow it access to a secure application executed in the TEE environment.

[0020] For this purpose, a hash value is calculated from the client application when it is executed, and the obtained 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 allowed to be established between the client application and the requested secure application. Otherwise, the session with the secure application is not established.

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

[0022] A second known solution comes from a technical standard developed by Global Platform, intended to help 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 the client applications 112.1 and 112.2 of [Fig.l], for establishing communications sessions with the secure applications 122.1 and 122.2 and with the 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 providing identification data, or login, such as data identifying the user under which the client application is executed, or the group of users under which the client application is executed, 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 provide or refuse access to its services to the client application.

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

[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 permitted 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 may provide services in response to requests from several different client applications in the unsecured 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.l], when the second client application 112.2 requires 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 verified according to the first known solution. There is thus no provision to verify that the second client application 112.2 is authorized to request a service from the first secure application 122.1.

[0029] Furthermore, in the first known solution, a new client application may be installed during a software update of the system 100, and a hash value of the new application is calculated during its execution. During this period, an attacker may 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 future establishment of 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 the storage of pre-calculated hash values in the TEE environment. This requires strict synchronization when storing pre-calculated hash values for client applications in the TEE environment. In case of an error when providing or loading the pre-calculated hash values, future authentications based on these hash values may be incorrect.

[0031] Concerning the second known solution, the aforementioned specifications document does not mention any standard for verifying the legitimacy of a client application. It is up to, when implementing the security of the rich operating system 111, to ensure the maintenance of the security of the client applications and the detection of any modification made in 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 identifier, a method called “TEEC_LOGIN_USER” in the aforementioned document corresponding to the second solution, a client application indicating the user identifier 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. When a client application is corrupted by an attacker, it can nevertheless retain its association with the user ID allowing it to access the service of the secure application. Thus, 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 group of users to which it belongs. However, no restriction is defined in the specification concerning the access of another client application, belonging to the same user or group of users, to this same secure application. Consequently, within client applications belonging to the same user or group of users, there is no partitioning of access to secure applications.

[0035] For example, referring to [Fig.l] described previously, 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.l], belongs to a second user different from the first user, then: - the first client application 112.1 can create and own 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 having 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 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 does not have any 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 the 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 thus a need to improve the security associated with the access of a client application to the service of a secure application executed 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 of a secure environment of a computer system, for establishing a current communication session between a client application of a non-secure 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 unsecured environment; - generation of a random number in the secure environment; - determination of 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 unsecured environment; - storing the unique identifier of the client application as metadata of the client application, in the unsecured environment; - following storage of the unique identifier in the unsecured environment, and receipt of a second request to establish a current session between the client application and the 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 of the client application materializing a unique link between the client application and the secure application. The unique character of this link is linked to the generation of a random number in the secure environment. The unique identifier is then used as verification data for the establishment of 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 service between a secure application and another client application. In addition, the proposed solution does not require prior storage of metadata relating to a client application in the secure environment. This thus avoids an update of the secure environment when installing a new client application in the non-secure environment.

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

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

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

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

[0046] According to embodiments, a data structure of the client application may comprise a 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 comprise, prior to the generation of the random number, a verification that the secure application identified in the first request is part of the list of at least one legitimate secure application of the data structure of the client application.

[0047] Thus, a prior check of the legitimacy of access to the secure application can be implemented. It is further made possible by the signature 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 thus ensured.

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

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

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

[0051] The extended attribute is a feature provided by some file systems. Moreover, such a feature may 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 may be stored as metadata in association with an identifier of the secure application.

[0053] Thus, unique links can be created, in a secure manner, 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 comprise 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 non-secure environment, and verifying the unique identifier of the client application prior to establishing the current communication session between the client application and the secure application may comprise the following steps: - obtaining a current hash value of the information uniquely identifying the secure application, by a trusted gateway of the unsecured environment; - transmission, by 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 obtained random number and from the current hash value.

[0055] Thus, it is possible to ensure that the entity having the unique identifier is indeed the client application for which the previous steps were implemented. The establishment of the current communication session is thus conditioned by such prior verification, which reinforces 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 unsecured environment capable of executing at least one client application, and a secure environment capable of executing at least one secure application, in which: - the unsecured environment comprises a rich kernel capable of, upon receipt of a first request from a client application, the first request identifying a secure application for which verification is required, obtaining information uniquely identifying the client application in the unsecured 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 core is configured to store the unique identifier of the client application as metadata of the client application in the untrusted environment; and - following storage of the unique identifier in the unsecured environment, and upon receipt by the rich core 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 establishing the current communication session between the client application and the secure application.

[0058] Other characteristics and advantages of the invention will appear on examining the detailed description below, and the appended drawings in which:

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

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

[0061] [Fig.3] illustrates a data structure of a client application, in an in system computer science 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 method of 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.l] illustrates a computer system 200 comprising a secure environment 220 and an unsecured environment 210, according to embodiments of the invention.

[0067] The computer system 200 is for example based on an ARM architecture of the ARM SoC 201 type. A secure monitor 202 is capable of ensuring an interface role between the non-secure environment 210 and the secure environment 220. The secure monitor 202 is a secure firmware, for example an ARM secure firmware, executed 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 executing 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 executing a set of secure applications, comprising for example a secure application 222, and possibly comprising other secure applications not shown in [Fig.2].

[0070] The unsecured environment 210 is executed 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 unsecured environment may be referred to as a “rich” or “main” operating system. For example, in the context of a computer system used for automotive applications, the main operating system may be Android Automotive OS™, or Automotive Grade Linux™.

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

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

[0073] The client application 212 may request services implemented by the secure application 222, via the secure monitor 202, and as described below. As part 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. The sensitive data may be any data originating from or used by the client application 212, such as private keys or personal information, such as personally identifiable information PII.

[0074] As explained previously, the client application 212 being executed in an unsecured 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 to 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, called a trusted gateway, between the non-secure environment 210, comprising the client application 212, and the secure environment 220. The functionalities implemented by the trusted gateway 213 will be better understood in the following. The trusted gateway can be considered as an API allowing access to the trusted zone that constitutes 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 in the motor vehicle. No restriction is attached to the function, or functions, performed by the client application 212.

[0077] The computer system 200 may initiate a secure boot, which is a known boot procedure, and which allows for 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, are cryptographically signed using a set of keys that are bound by a 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 software components of the user space, or non-secure environment 210, in on which the client application 212 is executed, are not part of the secure boot chain and therefore cannot be considered reliable or trusted. The invention, however, overcomes such a 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] The data structure 300 is an image of the binary file, or executable file, of the 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, no restriction being applied to the hash function considered.

[0083] A second additional section 303 may comprise 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 comprise 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 restriction is attached to the format of the identifier of the secure application 222 stored in the second additional section 303, which may be any identifier capable of uniquely identifying the secure application 222 in the secure environment 220. For example, the identifier of the secure application 222 may be a universally unique identifier, also called UUID, for "Universally Unique IDentifier" in English, which is a 128-bit identifier defined by the RFC 4122 standard.

[0086] A third additional section 304 may comprise 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 the list 303.

[0087] The output of the XOR operation may be passed to a cryptographically secure hash function, to determine a second hash value, as well. called “digital fingerprint” or “message digest” in English.

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

[0089] [Fig.4] shows 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 in the following, and aims to determine and store the data structure 300 of each client application 212 of the unsecured environment 210. No restriction is 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 source code of the application, in particular during the compilation of the source code of the client application 212.

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

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

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

[0094] In 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] In a step 404, the XOR function is applied to the first hash value and to the list of at least one secure application 222, to obtain a digital fingerprint.

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

[0098] In 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 indicated previously, the public key is then made accessible in the secure environment 220, for example stored in a memory of 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 a step 408, the first hash value is added to the binary source code of the client application 212 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 unsecured environment 110, in association with a file system path, from which the data structure 300 is accessible by the rich kernel 211.

[0102] [Fig.5] presents the steps of a verification phase of a client application, the verification phase being part of a method 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 previously, 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 trusted gateway 213, the secure kernel 221 and the secure applications it supports, including the secure application 222, as well as the firmware 202, have been signed and verified during a secure boot procedure, or “secure boot”, 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 unsecured environment 210, without this client application 212 being authorized to modify the attribute added by the gateway 213. Such an attribute may be an extended attribute, which may be associated with the binary source code 301 of the client application. For example, a POSIX functionality of the CAP_SYS_ADMIN type is disabled, so as to prevent the client application 212 from modifying the extended attribute which is assigned to its binary source code 301. POSIX is a set of standards from the IEEE, for "Institute of Electrical and Electronics Engineers" in English; - the file system of the unsecured environment 210 accepts the addition of attributes to client applications, such as the aforementioned extended attributes.

[0105] At a step 501 of the verification phase, the client application 212 is loaded into a volatile memory of the unsecured 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.

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

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

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

[0109] At a step 505, the trusted 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] In a step 506, the trusted 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 the following, 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 untrusted environment 210. Thus, in step 506, the trusted gateway 213 obtains the path of the file system 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 trusted gateway 213 calculates a first current hash value noted HCal, which is a hash value of the binary source code 301 of the client application 212 corresponding to the path of the file system obtained in the previous step.

[0112] In a step 508, the trusted gateway calculates a second current hash value, which is a hash value of the information uniquely identifying the client application 212 in the unsecured environment 210, that is to say, in the example considered, a hash value of the path from the file system to the source binary code 301 of the client application 212, obtained in step 506.

[0113] In a step 509, the trusted gateway 213 extracts the following information from the data structure 300 which it accesses from the file system path obtained in step 506: - the hash value, noted 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; - the list 303 stored in the second additional segment of the data structure 300 of the 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 from that shown in [Fig.5].

[0115] In a step 510, the trusted 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 HCASont different, the trusted gateway 213 interrupts the verification phase, and returns an error message to the client application 212, at a step 511. Thus, the comparison of step 510 makes it possible to ensure 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 a step 512, to the secure core 221: - the hash value HCal or HCa, which are identical, which corresponds to the hash value of the binary source code of the client application 212; - the list 303 comprising at least one secure application identifier, including the identifier of the secure application 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 the client application 212 in the unsecured environment 210, that is to say, in the example considered, the hash value of the path from the file system to the source binary code 301 of the 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] In a step 522, the secure application 222 verifies the signature of the signed hash value 304 received in step 520, from the public key obtained in step 521.

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

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

[0123] Step 522 thus makes it possible to verify that the signed hash value actually comes 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 digital 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 comprise: - applying, at a step 524, an XOR operation to the hash value HCa or Hcal and to the list 303, both received at step 520; - the calculation, at a step 525, of the third current hash value, also called current digital fingerprint, by applying a hash function to the result of the XOR operation.

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

[0126] In the event of a negative comparison, i.e. if the third current hash value obtained in step 525 does not correspond to the signed hash value 304 received in step 520, then the secure application 222 can transmit an error message to the trusted gateway 213, via the secure kernel 221, in a step 527. The trusted 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 in step 526, the secure application 222 verifies, in a step 528, that its own secure application identifier is present in the list 303 received in step 520.

[0128] In the event of a negative verification 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 trusted gateway 213, via the secure core 221, at a step 528.

[0129] On the contrary, in the event of a positive verification, 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 to a step 529. For this purpose, the secure application 222 can use a cryptographically secure random number generator in the secure environment 220.

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

[0131] In 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 non-secure 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 trusted platform 213 the CA ID identifier generated at step 530, which can confirm the verification of the client application 212 by the secure application 222 as well as the session identifier, 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 trusted gateway 213 previously described.

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

[0136] In a step 601, the trusted gateway 213 associates a pair comprising the unique identifier of the secure application 222 and the CA ID identifier, 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 functionality allowed in file systems such as EXT3 and EXT4 conventionally supported by Linux-based operating systems, in particular in the context of automotive applications. The extended attribute functionality makes it possible to securely store metadata of a file. 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 to which the client application 212 legitimately requests access. In this case, several key-value pairs are obtained, each pair identifying as 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 identifier 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 identifier is obtained and then stored in a first key-value pair in association with the unique identifier of the first secure application.Then, if the same client application 212 requests a session with a second secure application during a second verification phase, a second unique identifier CA ID is obtained and then stored in a second key-value pair in association with the unique identifier of the second secure application. Thus, several key-value pairs can be stored as extended attributes of the binary source code 301 of the client application 212.

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

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

[0140] The invention thus makes it possible to create a unique, non-modifiable 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 other sessions, subsequently, between the client application 212 and the secure application 222, as described with reference to [Fig.7].

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

[0143] In a step 701, the client application 212 is loaded into a volatile memory of the unsecured environment 210, by the rich kernel 211, 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 comprising a secure application identifier, such as the UIDD identifier of the secure application 222 with which the client application 212 requests the establishment of a session to access a service of the secure application 222, to the trusted gateway 213.

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

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

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

[0148] At a step 706, the trusted gateway 213 obtains the 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. As already described previously, such information may 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 file of the client application 212 is the path in the file system. Thus, at step 706, the trusted gateway 213 obtains the path of the file system 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, with the difference that steps 701 to 706 are implemented after the verification phase comprising steps 501 to 532.

[0150] At a step 707, the trusted 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 previously described is implemented from step 507.

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

[0153] In case of negative verification, that is to say if no key-value pair of the extended attributes of the client application 212 includes the identifier of the secure application 222 received in step 703, as a key, then the verification phase previously described is implemented from step 507.

[0154] On the contrary, in the event of a positive verification in step 708, the trusted gateway 213 obtains the unique identifier 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 non-secure environment 210, that is to say, in the example considered, a hash value of the path from the file system 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 requests the establishment of a current session.

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

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

[0158] In a step 721, the secure application 222 checks whether the secure application identifier included in the information received in step 720 corresponds to its own identifier.

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

[0160] On the contrary, in the event of a positive verification in step 721, the secure application 222 verifies, in a 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 non-secure environment 210, that is to say, in the example considered, a hash value of the path from the file system to the source binary code 301 of the client application 212, obtained in step 706.

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

[0162] On the contrary, in the event of a positive verification 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 identity CA ID included in the information received in step 720 has indeed been obtained from the current hash value and the random number obtained. For this purpose, the secure application 222 can apply an “exclusive or” operation, or XOR, to the random number obtained and to the unique identity 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. In the event of equality between the result of the operator and the current hash value, the secure application 222 determines that the unique identity CA ID included in the information received in step 720 was indeed obtained from the current hash value and the random number obtained.

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

[0164] If the secure application 222 determines in step 726 that the unique identity CA ID included in the information received in step 720 has indeed been obtained from the current hash value and the random number obtained, 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 in 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 verifying that the client application 212 is legitimate for establishing the current session with the secure application 222.

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

[0167] At a step 731, the trusted 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 a 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 thus avoids an update of the secure environment 220 when installing a new client application in the non-secure environment 210.

[0170] The present invention is not limited to the embodiments described above as examples; it extends to other variants.

Claims

Claims

1. Method for managing access to a secure application (222) of a secure environment (220) of a computer system (200), for establishing a current communication session between a client application (212) of a non-secure environment (210) of the computer system, and the secure application, the method comprising the following steps: - upon receipt (502) of 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 non-secure environment; - generation (530) of a random number in the secure environment; - determination (531) of a unique identifier of the client application, by the secure application, as a function of the generated random number and the information uniquely identifying the client application in the non-secure environment;- storage (601) of the unique identifier of the client application as metadata of the client application, in the non-secure environment; - following the storage of the unique identifier in the non-secure environment, and upon receipt (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. The method of claim 1, wherein the information uniquely identifying the client application (212) in the untrusted environment (222) is a path of the client application in a file system of the untrusted environment.

3. Method according to one of the preceding claims, in which the obtaining (506) of the information uniquely identifying the client application and the storage (601) of the unique identifier in the unsecured environment are implemented by a trusted gateway (213) of the unsecured environment (210), the method comprising a prior phase of secure startup of the system in- computer (200) during which the trusted gateway and each secure application (222) of the secure environment are signed by a set of keys of a trusted root.

4. Method according to one of the preceding claims, in which a data structure (300) of the client application (212) comprises a 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 in which, prior to the generation (530) of the random number, the method comprises a verification (528) that the secure application identified in the first request is part of the list of at least one legitimate secure application of the data structure of the client application.

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

6. The method of 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. Method according to one of the preceding claims, in which the unique identifier of the client application (212) is stored as metadata in association with an identifier of the secure application (222).

8. Method according to one of the preceding claims, in which, following the determination (531) of the unique identifier of the client application, the method further comprises the storage (532), in the secure environment (220), of an association between the generated random number and a hash value obtained from the information uniquely identifying the client application in the non-secure environment, and in which the verification (703-731) of the unique identifier of the client application prior to the establishment of 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 non-secure environment;- transmission (710), by 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 random number obtained and from the current hash value.

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

10. A computer system (200) comprising an unsecured environment (210) capable of executing at least one client application (212), and a secure environment (220) capable of executing at least one secure application (222), wherein: - the unsecured environment comprises a rich kernel (211) capable of, upon receipt of a first request from a client application, the first request identifying a secure application for which verification is required, obtaining information uniquely identifying the client application in the unsecured 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 as a function of the generated random number and the information uniquely identifying the client application in the unsecured environment; - the rich core is configured to store the unique identifier of the client application as metadata of the client application in the untrusted environment; and - following storage of the unique identifier in the unsecured environment, and upon receipt by the rich core 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 establishing the current communication session between the client application and the secure application.

Images