Method of managing privileges in a tamper-proof device comprising several software containers

1. A method for managing a secure element comprising a processor and an operating system configured to handle a set of communication protocols with external entities,

wherein the operating system accesses a ruling data specifying for each communication protocol of said set whether Card Lock, Card Terminate and Final Application privileges as defined by GlobalPlatform Card Specification are authorized or forbidden and wherein, upon receipt from one of said external entities of a command whose execution depends on one of said privileges, the operating system identifies which communication protocol of said set of communication protocols has been used to convey the command then uses the identified communication protocol as a discriminator to deny or to authorize said execution of said command based on the ruling data.

2. The method according to claim 1 , wherein the operating system uses a transport layer of the identified communication protocol as a discriminator to deny or to authorize execution of said command based on the ruling data.

3. The method according to claim 1 , wherein the secure element comprises both a first software container including a security domain compliant with GlobalPlatform Card Specification and a second software container including a Telecom profile compliant with GSMA Remote Provisioning Architecture for embedded UICC Technical Specification (SGP.02).

4. The method according to claim 1 , wherein the secure element comprises a registry storing a state set to SECURED, wherein the command is a SET STATUS requesting a change toward CARD_LOCKED state, said SECURED and CARD_LOCKED states and SET STATUS being compliant with GlobalPlatform Card Specification, and wherein the operating system denies execution of the command if the communication protocol used to convey the command is compliant with a transport layer protocol as defined by ETSI ISO7816-3, and wherein the operating system authorizes execution of the command if the communication protocol used to convey the command is compliant with SPI or SWP.

5. The method according to claim 4 , wherein the operating system receives, from a source internal to the secure element, a request to change toward CARD_LOCKED state and wherein the operating system denies execution of the request if the source belongs to a software container including a Telecom profile compliant with GSMA Remote Provisioning Architecture for embedded UICC Technical Specification.

6. The method according to claim 1 , wherein the set of communication protocols comprises T=0 or T=1 as defined by ETSI ISO7816-3 and at least one of SWP contactless type A, SWP contactless type B, SWP contactless type F, APDU Gate or SPI.

7. The method according to claim 1 , wherein the secure element is an embedded secure element, an integrated secure element, a secure enclave, a smart card or a Machine-To-Machine device.

8. A secure element comprising a hardware processor communicatively coupled to an operating system configured to handle a set of communication protocols with external entities,

wherein the operating system comprises a ruling data specifying for each communication protocol of said set whether Card Lock, Card Terminate and Final Application privileges as defined by GlobalPlatform Card Specification are authorized or forbidden, and wherein the operating system comprises a supervisor agent configured to, upon receipt from one of said external entities of a command whose execution depends on one of said privileges, identify which communication protocol of said set of communication protocols has been used to convey the command then to use the identified communication protocol as a discriminator to deny or authorize said execution of the command based on the ruling data

where said supervisor agent is a software component embedded in said operating system, and both said supervisor agent and said operating system comprise instructions which are executed by the hardware processor of the secure element.

9. The secure element according to claim 8 , wherein the supervisor agent is configured to use a transport layer of the identified communication protocol as a discriminator to deny or to authorize execution of said command based on the ruling data.

10. The secure element according to claim 9 , wherein the set of communication protocols comprises T=0 or T=1 as defined by ETSI ISO7816-3 and at least one of SWP contactless type A, SWP contactless type B, SWP contactless type F, APDU Gate or SPI.

11. The secure element according to claim 9 , wherein the secure element is an embedded secure element, an integrated secure element, a secure enclave, a smart card or a Machine-To-Machine device.

12. The secure element according to claim 9 , wherein the secure element is embedded in a host device.

13. The secure element according to claim 12 , wherein the host device is a phone, a watch, a pair of glasses, a car, a meter, a drone or a robot.

14. The secure element according to claim 8 , wherein the secure element comprises both a first software container including a security domain compliant with GlobalPlatform Card Specification and a second software container including a Telecom profile compliant with GSMA Remote Provisioning Architecture for embedded UICC Technical Specification.

15. The secure element according to claim 8 , wherein the secure element comprises a registry storing a state set to SECURED, wherein the command is a SET STATUS requesting a change toward CARD_LOCKED state, said SECURED and CARD_LOCKED states and SET STATUS being compliant with GlobalPlatform Card Specification, and wherein the operating system is configured to deny execution of the command if the communication protocol used to convey the command is compliant with a transport layer protocol as defined by ETSI ISO7816-3, and wherein the operating system is configured to authorize execution of the command if the communication protocol used to convey the command is compliant with SPI or SWP.