DE102019135121A1 - METHOD AND DEVICE FOR PROVIDING ADDITIONAL AUTHORIZATION FOR THE PROCESSING OF A CRYPTOGRAPHICALLY SECURED DATA SET FOR A PART OF A GROUP OF TRUSTED MODULES - Google Patents

Abstract

According to various embodiments, a method for providing an additional authorization for the processing of a cryptographically secured data record for a subset of a group of trustworthy modules is described, which comprises: generating a certificate of a key pair using a modified private key, the modified private key being a modification an originally configured private key which is linked to an original public key, generating a cryptographically secured data record using the key pair, selecting a subset of trustworthy modules from the group of trustworthy modules to which the data record is to be sent, sending the data record, the certificate and a modified public key associated with the modified private key or information on the basis of which the modified public Sc key can be derived from the original public key, to the subset and sending a signature, which depends on a cryptographic key generated for the subset of the group of trustworthy modules, for each trustworthy module of the subset, the signature being a signature of the modified public key and / or the information from which the modified public key can be derived, and verifying the signature, verifying the certificate and processing the data set by each trusted module of the subset.

Description

The present disclosure relates to methods and devices for providing an additional authorization for the processing of a cryptographically secured data record for a subset of a group of trustworthy modules.

In many applications it is desirable to be able to control to which subset of a group of secure elements (or more generally trustworthy modules) data, for example a command sequence, can be distributed. While the secure elements can be trusted, they can be part of devices (called hosts) whose security can be compromised. It should therefore be ensured that a compromised host cannot provide any data to a secure element that is not intended for the secure element. In addition, it may be desirable for a third party (i.e., a party other than the creator of the data and the secure element) to have this type of control; H. is provided with a mechanism that enables the party to ensure that only those secure elements are provided with the data that the third party wishes the data to be provided to them.

According to various embodiments, a method for providing an additional authorization for the processing of a cryptographically secured data record for a subset of a group of trustworthy modules is provided, comprising: generating a certificate of a key pair using a modified private key, the modified private key being a modification an originally configured private key, which is linked to an original public key, generating a cryptographically secured data record using the key pair, selecting a subset of trusted modules from the group of trusted modules to which the data record is to be sent, sending the data record, the certificate and one modified public key associated with the modified private key or information on the basis of which the modified public key lüssel can be derived from the original public key, to the subset and sending a signature which depends on a cryptographic key generated for the subset of the group of trustworthy modules for each trustworthy module of the subset, the signature being a signature of the modified public key and / or the information from which the modified public key can be derived, and verifying the signature, verifying the certificate and processing the data set by each trusted module of the subset. It should be noted that the signature can relate to a message authentication code or a signature according to a (e.g. elliptic curve) signature algorithm.

• 1 ein sicheres Element,
• 2 ein Flussdiagramm zur Dritte-Partei-Autorisierung eines Befehlsskripts,
• 3 ein Flussdiagramm, das eine GP-SCP1 1c(sicheres GlobalPlatform-Kanalprotokoll)-Personalisierung veranschaulicht,
• 4 ein Flussdiagramm, das eine SCP1 1c-Skripterzeugung und -verteilung veranschaulicht,
• 5 ein Flussdiagramm zur Dritte-Partei-Autorisierung eines Befehlsskripts gemäß einer Ausführungsform,
• 6 ein Flussdiagramm zur SE-Einzel-Dritte-Partei-Autorisierung eines Befehlsskripts gemäß einer Ausführungsform,
• 7 ein Flussdiagramm, das einen Wiederausführungsangriff veranschaulicht,
• 8 ein Flussdiagramm, das einen ersten Teil einer Alias-CA-SCP11c-Personalisierung/Konfiguration für eine OCE (Off-Card-Entität) veranschaulicht,
• 9 ein Flussdiagramm, das einen zweiten Teil der Alias-CA-SCP11c-Personalisierung/Konfiguration für eine dritte Partei veranschaulicht,
• 10 ein Flussdiagramm, das die SCP1 1c-Skripterzeugung und -verteilung gemäß Alias-CA-SCP11c veranschaulicht,
• 11 ein Flussdiagramm, das die Kommunikation zwischen einer OCE und einer Zertifizierungsstelle (CA) für die Erzeugung eines Standard-SCP11c-Skripts und von „n“ Alias-CA-SCP11c-Skripts gemäß einer Ausführungsform veranschaulicht,
• 12 ein Flussdiagramm, das die SCP11c-Skripterzeugung und -verteilung gemäß Alias-CA-SCP11c gemäß einer anderen Variante veranschaulicht,
• 13 ein Flussdiagramm, das die Alias-CA-Schlüsselableitung gemäß einer Ausführungsform detaillierter veranschaulicht,
• 14 ein Flussdiagramm, das ein Verfahren zum Bereitstellen einer zusätzlichen Autorisierung für die Verarbeitung eines kryptographisch gesicherten Datensatzes für eine Teilmenge einer Gruppe vertrauenswürdiger Module veranschaulicht, und
• 15 eine Vorrichtung zum Bereitstellen einer zusätzlichen Autorisierung für die Verarbeitung eines kryptographisch gesicherten Datensatzes für eine Teilmenge einer Gruppe vertrauenswürdiger Module.

In the drawings, like reference characters generally refer to the same parts throughout the different views. The drawings are not necessarily to scale and emphasis is placed on explaining the principles of the invention. In the following description, various aspects are described with reference to the following drawings. Show it:

• 1 a safe element
• 2 a flowchart for third party authorization of a command script,
• 3 a flow chart illustrating GP-SCP1 1c (Secure GlobalPlatform Channel Protocol) personalization,
• 4th a flow diagram illustrating SCP1 1c script generation and distribution,
• 5 a flowchart for third-party authorization of a command script according to an embodiment,
• 6th a flowchart for SE single third party authorization of a command script according to an embodiment,
• 7th a flowchart illustrating a re-execution attack
• 8th a flow diagram illustrating a first part of an alias CA-SCP11c personalization / configuration for an OCE (off-card entity),
• 9 a flowchart illustrating a second part of the alias CA-SCP11c personalization / configuration for a third party,
• 10 a flow diagram illustrating the SCP1 1c script generation and distribution according to Alias-CA-SCP11c,
• 11 a flow diagram illustrating the communication between an OCE and a certification authority (CA) for the generation of a standard SCP11c script and "n" alias CA-SCP11c scripts according to an embodiment;
• 12th a flowchart that illustrates the SCP11c script generation and distribution according to Alias-CA-SCP11c according to another variant,
• 13th a flowchart illustrating alias CA key derivation in accordance with one embodiment in greater detail;
• 14th a flowchart illustrating a method for providing additional authorization to process a cryptographically secured data set for a subset of a group of trusted modules, and
• 15th a device for providing an additional authorization for the processing of a cryptographically secured data record for a subset of a group of trustworthy modules.

The following detailed description refers to the accompanying drawings, wherein, by way of illustration, specific details and aspects of this disclosure are set forth in which the invention may be practiced. Other aspects can be used and structural, logical, and electrical changes can be made without departing from the scope of the invention. The various aspects of this disclosure are not necessarily mutually exclusive because some aspects of this disclosure can be combined with one or more other aspects of this disclosure to form new aspects.

1 shows a safe element 100 .

The safe element 100 or more generally a trusted module (e.g. a hardware trust root) can be an electronic device with one or more security domains 101 be in the form of a microcontroller, for example in a vehicle or a smart card module (a smart card with any form factor). The security domain 101 For example, it can store secure data such as cryptographic keys for performing secure operations.

The safe element 100 can be part of a host 104 , that is, a larger electronic device. For example, the secure element 100 be a secure part of a microcontroller which also has one or more non-secure domains, which in particular can have an interface via which the secure element 100 with external devices such as devices from off-card entities 105 , 106 communicates.

GlobalPlatform standardizes card content management (CCM) mechanisms for secure elements (SE). Typically, a service provider (SP) provides, for example, a first off-card entity 105 corresponds to an applet 103 ready and saves it within the security domain (SD) 101 (assigned to the service provider) on the SE 100 . Various off-card entities (OCEs) in the manner of a second OCE 106 may wish on the same SD 101 access, for example for in-field CCM (map content management) in the form of an update of the applet 103 .

1. 1. Sichere-Kanäle(SC)-Einrichtung
   • - Symmetrische Sichere-Kanäle-Protokolle (SCP), beispielsweise SCP01, SCP02, SCP03
   • - Asymmetrische SCPs, beispielsweise SCP10, SCP11, SCP22
2. 2. Privilegsprüfung von SD, wodurch CCM-Befehle empfangen werden:
   • - Autorisiertes Management (AM)
   • - Delegiertes Management (DM) über Tokens/Empfangsbestätigungen 3. Datenauthentifizierungsmuster (DAP/Mandated-DAP) für LADEN-Befehle 4. Skriptbasierte Autorisierung über Zertifikate:
   • - SEMS (Sichere-Elemente-Managementdienst) (Änderung I)
   • - DSEM (dezentralisiertes Sicheres-Elemente-Management) (= SCP11c) (Änderung F)

GlobalPlatform (GP) is currently standardizing four levels of authorization / authentication mechanisms:

1. 1. Secure Channels (SC) facility
   • - Symmetrical Secure Channel Protocols (SCP), e.g. SCP01, SCP02, SCP03
   • - Asymmetrical SCPs, for example SCP10, SCP11, SCP22
2. 2. Privilege check of SD, whereby CCM commands are received:
   • - Authorized Management (AM)
   • - Delegated management (DM) via tokens / acknowledgments of receipt 3. Data authentication pattern (DAP / Mandated-DAP) for LADEN commands 4. Script-based authorization via certificates:
   • - SEMS (Safe Elements Management Service) (Amendment I)
   • - DSEM (decentralized safe element management) (= SCP11c) (Amendment F)

GP authorizations are typically only given by the SE issuer or the service provider / OCE.

There are cases of use in which additional third-party authorization of CCM commands is desirable. One example is the SE 100 embedding device owner (OEM or Tier-1) who wants to control the handling of each SE individually (although he is not the author of a CCM command script, ie a sequence of CCM commands). For example, a device manufacturer can receive the SEs from an SE manufacturer who also generates the command script. The device manufacturer installs the SEs in devices and may be able to control which SEs the command script is fed to.

2 shows a flow chart 200 a third party authorization of an instruction script.

One OCE 201 , for example the OCE 105 corresponds to a third party 202 and a security domain 203 of an SE, for example the security domain 101 of the SE 100 are involved in the process.

It should be noted that when referring to an OCE or a third party performing an operation, it is to be understood that a corresponding electronic device (such as a server computer) of the OCE or the third party is performing the operation.

The process out 2 combines two separate authorization mechanisms.

In 204 generates the OCE 201 a single script for a group of SEs and therefore gives the entire group authorization to run it. She then sends the script in 205 to the third party.

The third party provides each SE in the group 206 individually ready an additional authorization. It then forwards the authorized script in 207 to each SE 203 further (via components, for example an interface, of the respective host of the SEs).

In 208 examines the SE 203 the authorization by the third party prior to the execution of the script.

It should be noted that it is desirable to have approaches to handling a scenario such as this 2 with a third party performing secondary authorization, maintain backward compatibility with existing GlobalPlatform certifiable configurations. It should also be noted that the GP authorization mechanisms 1 to 4 specified above (in particular SCP11c) do not allow this use case.

SCP11 is typically used in scenarios where there are no pre-shared keys between OCE 105 , 106 and SD 101 (or SE 100 ) exist. Any party 101 , 105 , 106 has its own asymmetric key pair and an associated certificate signed by a certificate authority (CA). This enables two entities (e.g. OCE 105 , 106 and SD 101 ) to establish a secure channel without using them in strict pairs.

The SCP1 Ic variant enables the safe channel to be opened for a given set of commands packed in a fixed script which are sent to SEs 100 belonging to a given group.

1. 1. Öffnen des sicheren Kanals
   • - Das Sicherheitsniveau wird AUTHENTIFIZIERT (Skriptautor ist der SD-Eigentümer)
   • - alle CCM-Befehle im Skript können ausgeführt werden
   • - Das Sicherheitsniveau wird DURCH_IRGENDJEMAND_AUTHENTIFIZIERT (Skriptautor ist nicht der SD-Eigentümer)
     • - nur im OCE-Zertifikat aufgelistete CCM-Befehle können ausgeführt werden
2. 2. Prüfen von SD-Privilegien
   • - Autorisiertes Management
     • - Token ist erforderlich, falls das Sicherheitsniveau DURCH_IRGENDJEMAND_AUTHENTIFIZIERT ist
   • - Delegiertes Management
     • - Token ist stets erforderlich

The authorization for generic CCM commands in SCP11c is twofold:

1. 1. Open the safe channel
   • - The security level is AUTHENTICATED (script author is the SD owner)
   • - all CCM commands in the script can be executed
   • - The security level is AUTHENTICATED BY SOMEONE (script author is not the SD owner)
     • - only CCM commands listed in the OCE certificate can be executed
2. 2. Checking SD privileges
   • - Authorized management
     • - Token is required if the security level is AUTHENTICATED BY SOMEONE
   • - Delegated management
     • - Token is always required

It should be noted that the owner of the script is identified by a specific data field in the OCE certificate. The GP OPEN function in the SE 100 compares this value with that in the SD receiving the script commands 101 is stored.

It should also be noted that because no re-execution prevention mechanism is defined in SCP11c, the range of CCM commands allowed in a script has been reduced (e.g. it should not be possible to change the life cycle state of a given entity in the SE).

1. 1. Personalisierungsphase, die (nur einmal) für eine Gruppe von SEs ausgeführt wird
2. 2. Schlüsselvereinbarungs- und SCP03-Sitzungsschlüsselerzeugung mit wechselseitiger Authentifizierung → Asymmetrische Kryptographie
3. 3. SCP03-Sitzung (verschlüsselte und signierte Kommunikation) → Symmetrische Kryptographie

Traditionally, SCP1 1c consists of three phases:

1. 1. Personalization phase which is carried out (only once) for a group of SEs
2. 2. Key agreement and SCP03 session key generation with mutual authentication → Asymmetric cryptography
3. 3. SCP03 session (encrypted and signed communication) → Symmetric cryptography

3 shows a flow chart 300 illustrating GP-SCP1 Ic personalization.

One OCE 301 , a certification authority (CA) 302 and multiple security domains 303 (from SEs) are involved in the process.

In 304 sends the OCE 301 their public key PK.OCE to the certification authority 302 with a request for a certificate for the OCE.

In 305 provides the certification body 302 the requested certificate CERT.OCE and the public key of the certification authority 302 PK.CA of the OCE 301 ready.

In 306 becomes the PK.SD of each group of SDs 303 the CA 302 provided as a certificate request.

In 307 the requested certificate CERT.SD and the public key PK.CA of the certification authority 302 the SD 303 provided.

4th shows a flow chart 400 , which illustrates SCP11c script generation and distribution.

The process takes place between an OCE 401 , for example the OCE 301 and a security domain 402 (of an SE), for example one of the security domains 303 corresponds to, instead of. As mentioned above, the security domain 402 Part of an SE in a host 403 be.

In 404 the SCP1 1c script generation is carried out. This includes the OCE 401 the SD certificate CERT.SD from the SD 402 received, CERT.SD verified with PK.CA and PK.SD extracted from CERT.SD.

The OCE 401 then generates an ephemeral OCE public key ePK.OCE and an ephemeral OCE private key eSK.OCE and a shared secret based on two static keys ShSss = ECKA (SK.OCE, PK. SD) and a shared secret based on a transitory key and a static key ShSes = ECKA (eSK.OCE, PK.SD), where ECKA stands for Elliptic Curve Key Agreement.

The OCE 401 also derives the SCP03 session key and an acknowledgment key from ShSss and ShSes and generates the script that they are in 405 to the host 403 sends.

In 406 Key agreement and session key generation are performed as part of SCP11c. This includes the transfer from CERT.OCE to the SD 402 about the host 403 . The SD 402 verifies CERT.OCE with PK.CA and extracts PK.OCE from CERT.OCE.

Furthermore, the SD 402 by the host 403 provided with ePK.OCE and determines the SD 402 ShSss through ShSss = ECKA (PK.OCE, SK.SD) and ShSes through ShSes = ECKA (ePK.OCE, SK.SD), where ECKA stands for Elliptic Curve Key Agreement, and forwards the SCP03 session keys and the confirmation of receipt key from ShSss and ShSes off. The SD 402 also calculates an acknowledgment of receipt, which it then sends to the host 403 sends.

In 407 finds the SCP03 session to send the script from the OCE 401 to the SD 402 instead of. The script can generally be a data record, in particular one or more commands, one or more response messages, etc. This includes the following operations: The host 403 forwards the script commands (or script components / data records in general) one after the other to the SD 402 continues and receives and stores the corresponding responses from the SD 402 . The host 403 forwards the acknowledgment of receipt and the responses to the OCE 401 further, which can optionally verify the confirmation of receipt.

1. 1. Das Fehlen einer skriptbasierten Dritte-Partei-Autorisierung
2. 2. Die Unmöglichkeit des Kombinierens von SE-Gruppen- und SE-Einzel-Autorisierungen
3. 3. Das Fehlen eines Wiederausführungsverhinderungs-Schutzmechanismus
4. 4. Ein begrenzter Funktionalitätsbereich infolge des Fehlens eines Wiederausführungsverhinderungs-Schutzmechanismus (in der Art der Unmöglichkeit einer Änderung des Lebenszyklus), während die Rückwärtskompatibilität mit einer existierenden GP-Konfiguration aufrechterhalten wird.

According to various embodiments, the following problems of the standard SCP11c (also referred to as standard SCP11c) are addressed:

1. 1. The lack of scripted third party authorization
2. 2. The impossibility of combining SE group and SE individual authorizations
3. 3. The lack of an anti-rerun protection mechanism
4. 4. A limited area of functionality due to the lack of an anti-re-execution protection mechanism (such as the inability to change lifecycle) while maintaining backward compatibility with an existing GP configuration.

According to various embodiments, this is achieved in that for each (new) script that is to be provided to SEs, the public / private key pair of the CA PK.CA/SK.CA is replaced by an alias (ie a modified version of PK.CA ' /SK.CA ') and a fresh OCE key pair PK.OCE' / SK.OCE ', a fresh derivation value r and the corresponding CERT.OCE' are generated. The resulting modified SCP1 1c protocol is referred to as Alias-CA-SCP11c.

The modified CA key pair PK.CA '/ SK.CA' is used to certify the fresh OCE key pair. The fresh OCE key pair is used as part of the SCP11c protocol to execute the key agreement that results in the generation of the script session keys and the receipt key. The replacement of the CA key pair with the alias and the generation of the fresh OCE key pair as well as the generation of the corresponding OCE certificate take place before the execution of the standard SCP11c script session (in 406 and 407 out 4th ) and are therefore transparent for the standard SCP11c implementation. These two previous operations (replacement of CA and OCE key pairs and certificates) can be omitted to remain compatible with traditional GP configurations.

In the approach according to various embodiments, the OCE and the CA have a very close relationship because the alias CA key derivation (i.e. the modification of keys) and the certificate request for each new scripting, i.e. H. for each generated script to be transferred. The OCE and CA roles can be assumed here, for example, by the service provider or the script author. (It should be noted that it is not a typical use case that the script author assumes the role of the CA. In a typical use case, the CA role is assumed by the issuer, which is presented to the service provider in digital form, in particular within the CERT.OCE certificate, This close connection is necessary so that the CA generates a fresh OCE certificate based on the fresh key pair of the OCE for each new script (by using the derived alias CA key). The CA may also have to sign its modified PK.CA ', which in a variant in which PK.CA' is sent directly to the SEs (without the derivation value r having to be sent), is forwarded to the SEs of the subset. It should be noted that the script itself should be executed on all SEs of a given SEs group. The SE single third party authorization is carried out by providing the derivative value or the modified PK.CA 'and authorizing its use by a signature for each individual SE.

In particular, embodiments allow third party authorization, as with reference to FIG 2 described. This is in 5 shown.

5 shows a flow chart 500 for third party authorization of an instruction script according to an embodiment.

Similar 2 are an OCE 501 , for example the OCE 105 corresponds to a third party 502 and a security domain 503 of an SE, for example the security domain 101 of the SE 100 is involved in the process.

In 504 generates the OCE 501 a single script for a group of SEs and therefore gives authorization to the whole group 509 . She then sends the script in 505 to the third party.

The third party puts in 506 an additional authorization 510 ready for the group of SEs. She then forwards the doubly authorized script in 507 to each SE 503 further (via components, for example an interface, of the respective host of the SEs).

In 508 examines the SE 503 the third party authorization 510 before running the script.

For example, third-party authorization from an OEM or Tier-1 may be desired, for example for in-field on-card data management and an application update of an HSM (hardware security module). Typically, a first authorization is given by the issuer to the script generator and then a second authorization is given by the device owner / manager. For example, the device owner may want to control the handling of each SE individually.

In the example from 5 could that from the OCE 501 script generated and authorized by the issuer according to the standard GP-SCP11 process can be executed by all SEs of the entire group of SEs. However, it may be desirable for the third party 502 can control which or which of the SEs in the group can execute the script. According to various embodiments, such functionality as in 6th shown provided.

6th shows a flow chart 600 for SE single third party authorization of a command script according to an embodiment.

Similar 5 are an OCE 601 , for example the OCE 105 corresponds to a third party 602 and security domains 603 of SEs, for example the security domain 101 of the SE 100 are involved in the process.

In 604 generates the OCE 601 a single script for a group of SEs and therefore gives authorization to the whole group 609 . She then sends the script in 605 to the third party.

The third party puts in 606 an additional authorization 610 ready for each individual SE in the group. She then forwards the authorized script in 607 to a specific (ie individual) SE 603 further (via components, for example an interface, of the respective host of the SEs).

In 608 examines the SE 603 the third party authorization 610 before running the script.

For example, SE individual authorization from an OEM or Tier-1 may be desired, for example for in-field on-card data management and application updates. Typically, a first authorization is given by the issuer to the script generator and then a second authorization is given by the device owner / manager. For example, the device owner may want to control the handling of each SE individually. For the OCE 601 is the maintenance of the SE single key material and the issuing of scripts for each SE 602 a heavy workload according to the standard SCP 11c and therefore an approach that is typically not for the OCE 601 is desirable.

As mentioned above, re-execution protection is provided in accordance with various embodiments.

7th shows a flow chart 700 illustrating a re-execution attack.

One OCE 701 , a security domain 702 (an SE) and an attacker 703 are involved in the process.

In example off 7th sends the OCE 701 in 704 a first script to save data, namely to update a key to the value "1", for the security domain 702 . The attacker 703 can the first script in 705 intercept.

Later the OCE broadcasts 701 in 706 a second script to save data, this time to update the key to the value "2", to the security domain 702 .

In 707 can the attacker 703 send the first script again and thereby return the key to the value "1".

• - Falls die OCE der Eigentümer der das Skript interpretierenden SD ist oder
• - falls die OCE nicht der Eigentümer der das Skript interpretierenden SD ist UND das „BF20“-Tag des CERT.OCE'-Zertifikats angibt, dass das DATEN-SPEICHERN erlaubt ist, UND falls das SE diesen Autorisierungsmechanismus unterstützt.

It should be noted that standard GP-SCP11c protocols prohibit the loading and deletion of keys via the SET KEY command. This operation remains possible via the SAVE DATA command:

• - If the OCE is the owner of the SD interpreting the script or
• - if the OCE is not the owner of the SD interpreting the script AND the "BF20" tag of the CERT.OCE 'certificate indicates that DATA STORAGE is allowed AND if the SE supports this authorization mechanism.

As in 7th however, a given script may be executed a second time by an unauthorized party. It can also happen that the script is accidentally run a second time by an authorized party.

Nonetheless, some use cases require the functionality of loading or updating keys in an SE. Therefore, according to various embodiments, an additional command is executed before the standard SCP11 script is started to check that the alias CA-SCP11c script that follows has not already been executed on the SE.

Without re-execution protection, a given script that updates a key in the SE could be intercepted by a hacker and executed again at a later time.

Another limitation of the standard GP-SCP11c protocol as a result of re-execution attacks is that changing the life cycle by the SET STATUS command is prohibited. However, some use cases require this functionality. Accordingly, the re-execution protection according to various embodiments mentioned above enables this limitation to be removed; H. the execution of this additional command defined command provides re-execution protection in such a way that it is no longer necessary to forbid the SET STATUS command. In other words, thanks to various embodiments, a life cycle change feature can be added by SCP11c scripting.

In a real use case, an OEM might want to block a given service from SEs in the field.

As mentioned above, a modified SCP11c protocol referred to as Alias CA-SCP11c is provided in accordance with various embodiments.

1. 1. Personalisierungsphase (die als der Standard-SCP11c-Personalisierung sehr ähnlich angesehen werden kann)
2. 2. Dynamische Alias-CA-SCP11c-Datenerzeugung (Alias-CA, OCE-Schlüsselpaare und OCE-Zertifikat)
3. 3. Dritte-Partei-Autorisierungserzeugung
4. 4. CA-Schlüsselableitung/(Empfang/Verifizierung) innerhalb des SEs
5. 5. Schlüsselvereinbarung und SCP03-Sitzungsschlüssel- und Empfangsbestätigungsschlüsselerzeugung mit wechselseitiger Authentifizierung → Asymmetrische Kryptographie
6. 6. SCP03-Sitzung (verschlüsselte und signierte Kommunikation) → Symmetrische Kryptographie (Empfangsbestätigungserzeugung + Verifizierung + Antwortnachrichtensammlung & Weiterleitung)

Alias-CA-SCP1 1c has six phases:

1. 1. Personalization phase (which can be viewed as very similar to the standard SCP11c personalization)
2. 2. Dynamic Alias-CA-SCP11c data generation (Alias-CA, OCE key pairs and OCE certificate)
3. 3. Third party authorization generation
4. 4. CA key derivation / (reception / verification) within the SE
5. 5. Key agreement and SCP03 session key and receipt key generation with mutual authentication → Asymmetric cryptography
6. 6. SCP03 session (encrypted and signed communication) → Symmetric cryptography (generation of receipts + verification + response message collection & forwarding)

8th shows a flow chart 800 which illustrates the first part of the Alias CA-SCP11c personalization / configuration.

One OCE 801 , a certification body 802 and a security domain 803 (of an SE) are involved in the process.

In 804 sends the OCE 801 their public key PK.OCE to the certification authority 802 with a request for a certificate for the OCE.

In 805 provides the certification body 802 the requested certificate CERT.OCE and the public key of the certification authority 802 PK.CA of the OCE 801 ready.

In 806 becomes the PK.SD of each group of SEs 803 the CA 802 as part of a certificate request for SD1 803 provided.

In 807 the requested certificate CERT.SD and the public key PK.CA of the certification authority 802 the SD 803 provided.

In other words, the SD receives 803 in 806 and 807 an SD certificate and a public CA key from the CA. 802 . This is only done during personalization (ie typically only done once).

The process can be performed for a group of security domains so that PK.SD, SK.SD and CERT.SD are the same for a group of SDs.

It should be noted that 804 , 805 in which the OCE 801 an OCE certificate from the CA 802 is only executed once during the personalization / configuration with the standard SCP11c. According to Alias-CA-SCP11c, as detailed below with reference to FIG 10 is described, a fresh OCE public key pair and its corresponding certificate are generated for each script (by replacing PK.OCE, SK.OCE and CERT.OCE that were used during personalization 8th exchanged), for example as part of the script generation process.

This is achieved by deriving a modified private key SK.CA 'used for generating a fresh OCE certificate CERT.OCE' and deriving the corresponding modified public key PK.CA 'used for the verification of this certificate. During SE personalization in 804 and 805 For reasons of GP compatibility, according to various embodiments, the executed OCE certificate request still remains part of the alias CA-SCP1 1c. The PK.CA used to verify the (initial) certificate CERT.OCE is temporarily exchanged for the newly created PK.CA 'within the SD while an alias CA-SCP1 Ic script is being executed. The modified keys SK.CA ', PK.CA' and the fresh certificate CERT.OCE 'are bound to be generated again every time a new script is created. This means that PK.CA is the original CA key used for compatibility with the standard SCP11c and can also be used as a starting point for the derivation of any further alias PK.CA '.

9 shows a flow chart 900 which illustrates a second part of the Alias CA-SCP11c personalization / configuration.

9 shows one of the OCE 801 corresponding OCE 901 and one of the certification body 802 corresponding certification body 902 . As in connection with 8th mentioned is a group of SDs 103 the same PK.SD, the same SK.SD and the same CERT.SD provided.

In the second part of the in 9 The personalization shown sends a third party 904 in 905 an individual third party authorization key SK.3P ₁ , SK.3P ₂ , ..., SK.3P _i for each SD of the group. It should be noted that it is also possible for a subset of several SEs within the group of SEs to receive the same SK.3P.

10 shows a flow chart 1000 , which illustrates the generation of an SCP1 1c script and its distribution according to Alias-CA-SCP11c.

The process takes place between an OCE 1001 , for example the OCE 801 , 901 corresponds to a certification body 1002 that for example the certification authority 802 , 902 corresponds to a third party 1003 that for example the third party 904 and a security domain 1004 (of an SE), the for example one of the group of security domains 803 , 903 corresponds to. The security domain 1004 can be part of an SE in a host 1005 be.

In 1006 becomes the alias CA key derivation by the OCE 1001 and the CA 1002 executed. This includes the derivation of key generation information (in other words a key generation parameter or key generation value) r (for example by the OCE 1001 executed). The key generation parameter r can, for example, be the hash value of a monotonic counter that is increased, for example, for each script generated. For example, this is a natural number.

The alias CA key derivation also includes the generation of SK.CA '= r + (SK.CA), where in this example it is assumed that SK.CA is a cryptographic private elliptic curve key in the form of a natural number. The OCE 1001 generates a fresh key pair PK.OCE 'and SK.OCE'. On the basis of SK.CA 'and the freshly generated PK.OCE', the CA 1002 CERT.OCE '.

In 1007 the (standard) SCP11c script generation is carried out. This includes the step in which the OCE 1001 the SD certificate CERT.SD from the SD 1004 received, CERT.SD verified with PK.CA and PK.SD extracted from CERT.SD.

The OCE 1001 then generates an ephemeral public OCE key ePK.OCE and an ephemeral private OCE key eSK.OCE and a shared secret based on two static keys ShSss = ECKA (SK.OCE ', PK. SD) and a shared secret on the Basis of a transitory key and a static key ShSes = ECKA (eSK.OCE, PK.SD), where ECKA stands for Elliptic Curve Key Agreement.

The OCE 1001 also derives the SCP03 session key and an acknowledgment key from ShSss and ShSes and generates the script that they are in 1008 to the third party 1003 sends. She also sends r to the third party.

The third party 1003 now authorizes each security domain that should run the script by authorizing the key derivation value r for each individual SD that should run the script.

This includes in 1009 the generation of a depending on SK.3P (the respective SD 1004 ) Message Authentication Codes (MAC) generated for the key derivation value r, for example a message containing r.

In 1010 sends the third party 1003 the key derivation value r (e.g. the message containing r) together with the MAC to the SD 1004 .

In 1011 verified the SD 1004 the MAC with the key SK.3P (which you can find in 905 of the process 9 had received). This means that the SD 1004 the third party authorization, ie whether it is from the third party 1003 has been authorized to run the script.

The SD also checks 1004 whether r has not already been used (for example, previously received for a previous script) to protect against re-execution attacks.

If both the verification of the MAC and the test were positive, the SD generates 1004 the modified PK.CA 'to PK.CA' = r * G + PK.CA, where G is the base point of the Elliptic Curve cryptography algorithm.

In 1012 A key agreement and session key generation are carried out according to the standard SCP11c, but with PK.CA 'instead of PK.CA.

This includes the transfer of CERT.OCE 'to the SD 1004 about the host 1005 . The SD 1004 verifies CERT.OCE 'with PK.CA' and extracts PK.OCE 'from CERT.OCE'.

Furthermore, the SD 1004 by the host 1005 (who in turn received him from the OCE 1001 receives) provided with ePK.OCE and calculates the SD 1004 ShSss = ECKA (PK.OCE ', SK.SD) and ShSes after ShSes = ECKA (ePK.OCE, SK.SD) and derives the SCP03 session key and the confirmation of receipt key from ShSss and ShSes. The SD 1004 also determines an acknowledgment of receipt, which it sends as a response to the host 1005 sends.

In 1013 finds the SCP03 session to send the record from the OCE 1001 to the SD 1004 instead of. This includes the step in which the host 1003 the script commands one after the other to the SD 1004 forwards and the corresponding answers of the SD 1004 receives and stores. The host 1005 forwards the acknowledgment of receipt and the responses to the OCE 1001 further, which can optionally verify the confirmation of receipt.

The introduction of the key derivative value r introduces variability and prevents a SE from a given subset of a SE group from using a script issued for another subset of the same SE group. The generation of the key derivation value r based on a monotonic counter by the OCE 1001 and checking by the SD 1004 the fact that r has not yet been used prevents the script that was already running from being re-executed. The key derivation value r serves as authorization for any element of a group of SDs (or SEs) to execute the generated script. The MAC MAC_SK.3P (r) is the authorization for a single individual SD (or a single individual SE) to execute the script (ie all SEs that share the same SK.3P).

The process out 10 can be viewed as the standard SCP11c scenario. The only difference is that the PK.CA has been replaced by the PK.CA 'that the SD 1004 after receiving the MAC, for example with an introduced ALIAS DERIVATE command. This means that the process is the same as in the standard GP context if the DERIVATE ALIAS command is not executed before the EXECUTE SAFETY OPERATION command by which the SD 1004 is provided with the OCE certificate.

As mentioned above, the SD 1004 to prevent re-execution of a script that has already been run, the ability to check that the key derivation value r was not used in a previous script run. As in 10 as shown, it can perform this test during the DERIVATE ALIAS command (or after it is received) and before replacing PK.CA with PK.CA '.

The precondition for initiating cryptographic wrapping is through PK.OCE '(through the SD 1004 extracted from CERT.OCE ') is linked to the r-value and is therefore different from previously executed scripts.

11 shows a flow chart 1100 that the communication between the OCE 1101 (for example according to the OCE 1001 ) and the certificate authority 1102 (for example according to the CA 1002 ) for the scripts 1103 , 1104 , 1105 illustrated.

After the standard personalization in 1106 , including providing an initial OCE certificate CERT.OCE which can be used to generate one or more standard SCP11c scripts, a fresh OCE key pair along with a new r-value is created by the OCE 1101 generated for each new script (i.e. each time a new script is generated) that is created in the Alias-CA-SCP11c process in 1107 and 1108 is used. The CA 1102 uses the r-value to derive an alias-SK.CA 'used to generate the OCE certificate CERT.OCE'.

For standard SCP11c scripts 1103 the original PK.OCE and SK.OCE are used for script generation and distribution (such as in 4th described). For the Alias CA SCP11c scripts 1104 and 1105 the PK.OCE 'and SK.OCE' generated for each script are used instead (as in 10 described). The SE only carries out an unwrapping operation of the script in the Alias-CA-SCP1 Ic mode if it has received the DERIVATE ALIAS command in advance and was able to execute it successfully. Otherwise the SE should behave in the normal SCP11c mode and use the PK.OCE (from the standard personalization 1106 emerged).

Accordingly, according to various embodiments, instead of using the CA key pair PK.CA/SK.CA (in the standard SCP11c protocol is used for the CA to generate the OCE certificate and for the SD to verify it ) a derived alias CA key pair PK.CA '/ SK.CA' is used. The alias key SK.CA 'is used by the CA to generate the CERT.OCE' for a given script. The DERIVATE ALIAS command is added to the script. It contains the derivation parameter r secured with a signature (for example in the form of a MAC). The signature is verified using the SE single (or subset single or group single) third party authorization key SK.3P (by the SE, for example on-card in the case of a chip card). If the verification fails, the processing of the DERIVATE ALIAS command is interrupted and the standard PK remains. CA key set for using the SCP11c protocol. However, if the verification of the MAC is successful, the received derivation parameter r is used by the SE to derive the alias-PK.CA '. This alias is then defined for use in the upcoming SCP1 Ic channel setup (for the verification of CERT.OCE 'and the extraction of PK.OCE'). Immediately after use, or if an error or reset occurs during the SCP11c channel setup, the SE clears the PK.CA 'and uses the PK.CA for any further standard SCP11c session setups. It should be noted that falling back to the standard PK.CA/SK.CA key pair for establishing a standard SCP11c channel is simply not to (successfully) execute the proprietary DERIVATE ALIAS command. The alias CA-SCP11c can accordingly be viewed as a backward-compatible extension of the standard SCP11c definition.

Table 1 below gives an overview of the key material and certificates that are used in Alias-CA-SCP11c according to various embodiments. Table 1 Data description Group clearly SE clearly Script unique Secret PK.OCE OCE public key x SK.OCE private OCE key x x PK.OCE ' newly generated public OCE key for each script x SK.OCE ' newly generated private OCE key for each script x x CERT.OCE OCE certificate signed by CA with SK.CA x CERT.OCE ' OCE certificate signed by CA with Alias-SK.CA ' x PK.SD public SD key x SK.SD private SD key x x CERT.SD SD certificate signed by CA with SK.CA x PK.CA public CA key x SK.CA private CA key x x PK.CA ' derived CA public key x SK.CA ' Derived private CA key x x ePK.OCE ephemeral OCE public key x eSK.OCE ephemeral OCE private key x x ShSss shared secret based on two static keys x x ShSes shared secret based on an ephemeral key and a static key x x SCP03 keys symmetric keys required for GP-SCP03 x x SK.3P symmetric third party authorization key x x r random derivation parameter for PK.CA 'and SK.CA' derivation x SK.3P.ECDSA Third Party Asymmetric Private Authorization Key x x PK.3P.ECDSA third party asymmetric public authorization key x d_SD _X Derivation value for third party authorization key x SK.3P_Master Master key for third party authorization key derivation x x SK.3Pd _x derived third party authorization key x x

According to one embodiment, depending on an additional cryptographic key k, instead of using a hash of a monotonic counter for the key derivation parameter, another cryptographic function can be applied to the monotonic counter, for example an AES (Advanced Encryption Function). In other words, in the process of 10 the value r is replaced by AES k (monotonic counter).

According to one embodiment, instead of using the key SK.3P and a MAC, an asymmetric authorization key pair together with an elliptic curve digital signature algorithm (ECDSA) is used as the signature. This means that when it expires 10 Signature = MAC_SK.3P (r) is replaced by signature = ECDSA (r, SK.3P.ECDSA), where SK.3P.ECDSA is the private authorization key, and SD 1004 in 1011 the signature verified by PK.3P.ECDSA. This is in 12th shown.

12th shows a flow chart 1200 , which illustrates the generation of the SCP11c script and its distribution according to Alias-CA-SCP11c according to another variant.

The process out 12th is similar to the process 10 except that in 1209 the signature is calculated using an elliptic curve digital signature algorithm rather than a MAC. The SD verified accordingly 1204 in 1211 the signature using the corresponding public key PK.3P.ECDSA.

According to one embodiment, the third party uses a key derivation for the third party authorization key (with an SK.3P master key SK.3P_Master). This means that the third party is in the process of being out 10 in 1009 derives a key SK.3Pd _{x based on a derivation value dSD X} previously derived from SE and SK.3P_Master and calculates the signature as signature = MAC_SK.3Pd (r). The SE 1004 verifies the signature using SK.3Pd _x in 1011.

13th shows a flow chart 1300 10, which illustrates in greater detail alias CA key derivation according to one embodiment.

The process out 13th corresponds, for example, to the alias CA key derivation of 1006 of the process 10 for the distribution of a newly created script. The process takes place accordingly between an OCE 1301 and a certification body 1302 instead of.

In 1303 generates the OCE 1301 a new key derivative value r that you put in 1304 to the CA 1302 sends.

In 1305 generates the OCE 1301 a new OCE key pair PK.OCE 'and SK.OCE' (together with a fresh r).

In 1306 sends the OCE 1301 the newly generated public key PK.OCE 'to the CA 1302 and leads in 1307 a new private certification authority alias key SK.CA '= r + (SK.CA). It also creates a new OCE certificate CERT.OCE 'using SK.CA'.

In 1308 sends the CA 1302 the newly created OCE certificate for the OCE 1301 .

In other words, according to various embodiments, a method is provided as shown in FIG 14th is shown.

14th shows a flow chart 1400 , which illustrates a method for providing additional authorization to process a cryptographically secured data set for a subset of a group of trusted modules.

The names of the various keys and certificates used in the above examples are included below for better understanding.

In 1401 a certificate (CERT.OCE ') of a key pair is generated using a modified private key (SK.CA'), the modified private key (SK.CA ') being a modification of an originally configured private key (SK.CA) with a original public key is linked.

In 1402 a cryptographically secured data record is generated using the key pair (for cryptographically securing the data record).

In 1403 a subset of trustworthy modules of the group of trustworthy modules to which the data set is to be supplied is selected.

In 1404 the data record, the certificate (CERT.OCE ') and a public key (PK.CA') for the modified private key (SK.CA ') or information (r) on the basis of which the public key (PK.CA') for the modified private key (SK.CA ') can be derived from the original public key, sent to the subset.

Furthermore, a signature (for example a message authentication code), which depends on a cryptographic key (SK.3P) generated for the subset of the group of trustworthy modules, is sent for each trustworthy module of the subset, the signature being a signature of the modified public key (PK. CA ') and / or the information (r) from which the modified public key (PK.CA') can be derived.

In 1405 each trusted module of the subset verifies the signature, verifies the certificate (CERT.OCE ') and processes the data set (which may include unwrapping the data set).

According to various embodiments, the party (for example a data processing component such as a network component) that carries out the transmission (for example a third party) can, in other words, determine which trustworthy module (for example security domain of an SE) is enabled to issue the certificate (CERT .OCE '), because this party can determine which trusted module they should use to obtain the public key (PK.CA') for the modified private key or the information (r) that the public key (PK.CA ') is used for the modified private key can be derived. The party does this by sending the public key (PK.CA ') for the modified private key or the information (r) from which the public key (PK.CA') for the modified private key can be derived with a signature (or a day). For each subset of a group, this signature depends on a cryptographic key (SK.3P) which is specific for the trustworthy module of the subset (or several trustworthy modules of the subset). According to one embodiment, this cryptographic key (SK.3P) can be generated for several trustworthy modules of the subset. Accordingly, it can be ensured that trustworthy modules outside the subset do not use the public key (PK.CA ') for the modified private key or the information (r) on the basis of which the public key (PK.CA') for the modified private key can be derived by the party. The key can be a shared key for the entire subset.

It should be noted that the data record (e.g. a command script) can be received by a trustworthy module that does not belong to the subset but to the group of trustworthy modules (e.g. because it was sent to all SEs in the group or because the host of the trustworthy module has been compromised ). However, it is assumed that the trusted module is secure and that it can be trusted not to run the script if it has not been allowed to verify the certificate (CERT.OCE '), i.e. if it does not have the signature or the tag was provided (e.g. via the key derivation value r). With a compromised host, it might be possible to send just PK.CA 'or r. In this case, however, the corresponding signature or tag would be missing.

The “additional” authorization can accordingly be viewed in such a way that it allows a trustworthy module to verify the certificate (CERT.OCE '). This can be viewed as an authorization in addition to the authorization given to the CA in the form of a certificate (CERT.OCE ').

The approach out 14th provides a mechanism to provide a third party with the ability to also provide script execution authorization of a given subset of an SE group. This includes, for example, an authorized session key generation, which increases the variability in the script generation process.

For example, according to various embodiments, a method is provided for cryptographically combining or linking two types of script authorization, including script content authorization performed by the script author (OCE / SP) for an SE group and one or more third parties (device owner / OEM / TSM) at one existing script (subsequent / additional authorization) script execution authorization carried out individually for each SE or for a subset of SEs belonging to the aforementioned SE group.

Embodiments allow the addition of a third party (or even multiple parties, for example in the form of a third party chain) authorization and a SE single authorization to GlobalPlatform SCP11c scripts without the SP / OCE having to write an individual script for each SE would have to generate, thereby reducing the burden of individually addressing each SE from the SP / OCE perspective. Furthermore, embodiments allow additional parties to control script execution individually at the SE level or a subset level (compared to the authorization given at the group level by the OCE).

• - Entweder ist OCE/SP der Eigentümer der Ziel-SD, wobei dann fast alle CCM-Aktionen erlaubt sind, oder
• - OCE ist nicht der Eigentümer der Ziel-SD, sondern hat ihre eigenen CCM-Rechte (d. h. Rechte, das Karteninhaltsmanagement auszuführen) und Beschränkungen, die in ihrem CERT.OCE-Zertifikat gespeichert sind - wenn der Mechanismus nicht unterstützt wird, ist jedoch keine Aktion erlaubt Ausführungsformen sehen eine flexiblere Autorisierung durch eine dritte Partei vor.

Embodiments also make it possible to circumvent the limitations of the conventional SCP11c. In particular, the authorization for the standard SCP11c is bivalent and rigid:

• - Either OCE / SP is the owner of the target SD, in which case almost all CCM actions are allowed, or
• - OCE is not the owner of the target SD, but has its own CCM rights (i.e. rights to perform card content management) and restrictions stored in its CERT.OCE certificate - but if the mechanism is not supported, it is not Action Allowed Embodiments provide for more flexible third-party authorization.

Furthermore, according to conventional SCP11c, neither SET STATUS nor SET KEY commands are allowed, while embodiments allow all CCM commands to be executed without exception.

In addition, embodiments provide a re-execution prevention mechanism for SCP11c scripting, for example protecting against an attacker using DATA SAVE from overwriting older data and / or key material. This enables unlimited CCM script based SE handling.

According to one embodiment, each trustworthy module can typically check for re-execution protection whether the key derivation value meets a predetermined criterion, for example lies within a certain value range, is even (or odd), has a certain size, has a certain something, etc. Only if the If the key derivation value meets the specified criterion, the trustworthy module continues with the PK.CA 'derivation and the processing of the data by the SCP11c script (with an instruction script being executed, for example).

It should be noted that, according to embodiments described above, key derivation information (ie, for example, the value r) is transmitted. However, this is just an example, and it can, as in 14th described, the fully modified public key for the modified secret key can also be sent to the subset of trusted modules (ie for exemplary security domains). However, an additional signature can be provided for the modified public key in order to enable the trustworthy modules to verify, for example, that the modified public key originates from the certification authority.

It should also be noted that the key derivation information does not necessarily have to be transmitted by a separate information element, but can be transmitted, for example, as part of the certificate (CERT.OCE '), for example in a “freely available data” field.

15th shows an apparatus 1500 to provide an additional authorization for the processing of a cryptographically secured data record for a subset of a group of trustworthy modules.

The device 1500 assigns a recipient 1501 which is designed to receive a cryptographically secured data record and a certificate of a key pair used to secure the generated data record using a modified private key, the modified private key being a modification of an originally configured private key that is associated with an original public key is linked.

The device also has 1500 a voter 1502 which is designed to select a subset of trusted modules of the group of trusted modules to which the data set is to be fed.

The device 1500 also has a transmitter 1503 which is designed to include the data set, the fresh certificate and the modified public key associated with the modified private key or information from which the public key for the modified private key can be derived from the original public key to the subset and for each trustworthy module of the subset a signature which depends on a cryptographic key generated for the subset of the group of trustworthy modules, the signature being a signature of the modified public key and / or the information on the basis of which the modified public key is derived can be to send.

The components of the device 1500 and the components of the other devices described herein can be implemented by one or more circuits. According to one embodiment, a “circuit” can be understood as any type of logic implementing entity, which can be hardware, software, firmware, or a combination thereof. Accordingly, according to one embodiment, a “circuit” may be a hardwired logic circuit or a programmable logic circuit such as a programmable processor, for example a microprocessor. A “circuit” can also be software implemented or executed by a processor, for example any type of computer program, for example a computer program that uses virtual machine code such as Java, for example. Any other type of implementation of the respective functions described here can also be understood as a “circuit” according to an alternative embodiment.

• Beispiel 1 ist ein Verfahren zum Bereitstellen einer zusätzlichen Autorisierung für die Verarbeitung eines kryptographisch gesicherten Datensatzes für eine Teilmenge einer Gruppe vertrauenswürdiger Module, wie mit Bezug auf 14 beschrieben.
• Beispiel 2 ist das Verfahren nach Beispiel 1, wobei jedes vertrauenswürdige Modul der Teilmenge den Datensatz verarbeitet, falls es die Signatur und das Zertifikat erfolgreich verifiziert.
• Beispiel 3 ist das Verfahren nach Beispiel 1 oder 2, wobei jedes vertrauenswürdige Modul der Teilmenge das Zertifikat durch den modifizierten öffentlichen Schlüssel verifiziert.
• Beispiel 4 ist das Verfahren nach einem der Beispiele 1 bis 3, wobei für jedes vertrauenswürdige Modul der Teilmenge der modifizierte öffentliche Schlüssel oder Informationen, anhand derer der modifizierte öffentliche Schlüssel abgeleitet werden kann, durch eine Nachricht zum vertrauenswürdigen Modul gesendet werden und das vertrauenswürdige Modul den modifizierten öffentlichen Schlüssel anhand der Nachricht bestimmt, falls es die Signatur erfolgreich verifiziert.
• Beispiel 5 ist das Verfahren nach einem der Beispiele 1 bis 4, wobei der ursprüngliche öffentliche Schlüssel ein in den vertrauenswürdigen Modulen der Gruppe vertrauenswürdiger Module gespeicherter öffentlicher Schlüssel ist.
• Beispiel 6 ist das Verfahren nach Beispiel 5, wobei der ursprüngliche öffentliche Schlüssel der Gruppe vertrauenswürdiger Module vor der Erzeugung des Datensatzes zugeführt wurde.
• Beispiel 7 ist das Verfahren nach einem der Beispiele 1 bis 6, wobei die Informationen, anhand derer der modifizierte öffentliche Schlüssel abgeleitet werden kann, gesendet werden und jedes vertrauenswürdige Modul der Teilmenge den modifizierten öffentlichen Schlüssel unter Verwendung der Informationen ableitet.
• Beispiel 8 ist das Verfahren nach einem der Beispiele 1 bis 7, wobei die Erzeugung des kryptographisch gesicherten Datensatzes durch eine erste Datenverarbeitungskomponente ausgeführt wird und die Auswahl und das Senden durch eine zweite Datenverarbeitungskomponente ausgeführt werden und ferner der kryptographisch gesicherte Datensatz von der ersten Datenverarbeitungskomponente der zweiten Datenverarbeitungskomponente bereitgestellt wird.
• Beispiel 9 ist das Verfahren nach Beispiel 8, wobei ferner jedem der vertrauenswürdigen Module durch die zweite Datenverarbeitungskomponente der kryptographische Schlüssel für die Signatur bereitgestellt wird.
• Beispiel 10 ist das Verfahren nach einem der Beispiele 1 bis 9, wobei die vertrauenswürdigen Module Sicherheitsdomänen sicherer Elemente sind.
• Beispiel 11 ist das Verfahren nach einem der Beispiele 1 bis 10, wobei der kryptographisch gesicherte Datensatz erzeugt wird, das Zertifikat erzeugt wird und der Datensatz gemäß dem sicheren GlobalPlatform-Kanalprotokoll 11c zur Teilmenge gesendet wird.
• Beispiel 12 ist das Verfahren nach einem der Beispiele 1 bis 11, wobei der kryptographisch gesicherte Datensatz einen oder mehrere Befehle umfasst und bei der Verarbeitung des Datensatzes der eine oder die mehreren Befehle ausgeführt werden.
• Beispiel 13 ist das Verfahren nach Beispiel 12, wobei der eine oder die mehreren Befehle einen Befehl zum Festlegen eines Status der vertrauenswürdigen Module der Teilmenge und/oder einen Befehl zum Speichern eines kryptographischen Schlüssels in den vertrauenswürdigen Modulen der Teilmenge umfassen.
• Beispiel 14 ist das Verfahren nach einem der Beispiele 1 bis 13, wobei die Informationen, anhand derer der modifizierte öffentliche Schlüssel abgeleitet werden kann, gesendet werden und ferner jedes vertrauenswürdige Modul der Teilmenge prüft, ob die Informationen ein vorgegebenes Wiederausführungsschutzkriterium erfüllen, und die Daten nur dann verarbeitet werden, falls die Informationen das vorgegebene Wiederausführungsschutzkriterium erfüllen.
• Beispiel 15 ist das Verfahren nach Beispiel 14, wobei das vorgegebene Wiederausführungsschutzkriterium darin besteht, dass die Informationen noch nicht in Zusammenhang mit einem zum vertrauenswürdigen Modul gesendeten Datensatz verwendet wurden und/oder dass die Informationen einen Wert innerhalb eines vorgegebenen Wertebereichs aufweisen.
• Beispiel 16 ist das Verfahren nach Beispiel 1 bis 15, wobei der modifizierte öffentliche Schlüssel zur Teilmenge gesendet wird und ferner eine zusätzliche Signatur für den modifizierten öffentlichen Schlüssel gesendet wird und die zusätzliche Signatur von jedem vertrauenswürdigen Modul der Teilmenge verifiziert wird.
• Beispiel 17 ist eine Vorrichtung zum Bereitstellen einer zusätzlichen Autorisierung für die Verarbeitung eines kryptographisch gesicherten Datensatzes für eine Teilmenge einer Gruppe vertrauenswürdiger Module, wie mit Bezug auf 15 beschrieben.
• Beispiel 18 ist die Vorrichtung nach Beispiel 17, wobei der Sender dafür ausgelegt ist, die Informationen zu senden, anhand derer der modifizierte öffentliche Schlüssel abgeleitet werden kann.
• Beispiel 19 ist die Vorrichtung nach Beispiel 17 oder 18, wobei der eine oder die mehreren Befehle einen Befehl zum Festlegen eines Status der vertrauenswürdigen Module der Teilmenge und/oder einen Befehl zum Speichern eines kryptographischen Schlüssels in den vertrauenswürdigen Modulen der Teilmenge umfassen.
• Beispiel 20 ist die Vorrichtung nach einem der Beispiele 17 bis 19, wobei der Sender dafür ausgelegt ist, den modifizierten öffentlichen Schlüssel zur Teilmenge zu senden und eine zusätzliche Signatur für den modifizierten öffentlichen Schlüssel, die von jedem vertrauenswürdigen Modul der Teilmenge zu verifizieren ist, zu senden.
• Beispiel 21 ist ein Datenverarbeitungssystem, das die Vorrichtung nach einem der Beispiele 17 bis 20 umfasst, wobei es ferner ein oder mehrere vertrauenswürdige Module der Teilmenge umfasst, wobei jedes vertrauenswürdige Modul dafür ausgelegt ist, die Signatur zu verifizieren, das Zertifikat zu verifizieren und den Datensatz zu verarbeiten.
• Beispiel 22 ist das Datenverarbeitungssystem nach Beispiel 21, wobei jedes vertrauenswürdige Modul der Teilmenge dafür ausgelegt ist, den Datensatz zu verarbeiten, falls es die Signatur und das Zertifikat erfolgreich verifiziert.
• Beispiel 23 ist das Datenverarbeitungssystem nach Beispiel 21 oder 22, wobei der Sender dafür ausgelegt ist, für jedes vertrauenswürdige Modul der Teilmenge den modifizierten öffentlichen Schlüssel oder Informationen, anhand derer der modifizierte öffentliche Schlüssel abgeleitet werden kann, durch eine Nachricht zum vertrauenswürdigen Modul zu senden, und das vertrauenswürdige Modul dafür ausgelegt ist, den modifizierten öffentlichen Schlüssel anhand der Nachricht zu bestimmen, falls es die Signatur erfolgreich verifiziert.
• Beispiel 24 ist das Datenverarbeitungssystem nach einem der Beispiele 21 bis 23, wobei der kryptographisch gesicherte Datensatz einen oder mehrere Befehle umfasst und bei der Verarbeitung des Datensatzes der eine oder die mehreren Befehle ausgeführt werden. Beispiel 25 ist das Datenverarbeitungssystem nach einem der Beispiele 21 bis 24, wobei jedes vertrauenswürdige Modul der Teilmenge dafür ausgelegt ist, das Zertifikat durch den modifizierten öffentlichen Schlüssel zu verifizieren.
• Beispiel 26 ist das Datenverarbeitungssystem nach einem der Beispiele 21 bis 25, wobei die vertrauenswürdigen Module der Teilmenge dafür ausgelegt sind, den ursprünglichen öffentlichen Schlüssel zu speichern.
• Beispiel 27 ist das Datenverarbeitungssystem nach einem der Beispiele 21 bis 26, wobei der Sender dafür ausgelegt ist, die Informationen, anhand derer der modifizierte öffentliche Schlüssel abgeleitet werden kann, zu senden, und jedes vertrauenswürdige Modul der Teilmenge dafür ausgelegt ist, den modifizierten öffentlichen Schlüssel unter Verwendung der Informationen abzuleiten.
• Beispiel 28 ist das Datenverarbeitungssystem nach einem der Beispiele 21 bis 27, wobei der Sender dafür ausgelegt ist, die Informationen, anhand derer der modifizierte öffentliche Schlüssel abgeleitet werden kann, zu senden jedes vertrauenswürdige Modul der Teilmenge dafür ausgelegt ist, zu prüfen, ob die Informationen ein vorgegebenes Wiederausführungsschutzkriterium erfüllen, und die Daten nur dann zu verarbeiten, falls die Informationen das vorgegebene Wiederausführungsschutzkriterium erfüllen.
• Beispiel 29 ist das Datenverarbeitungssystem nach einem der Beispiele 21 bis 28, wobei das vorgegebene Wiederausführungsschutzkriterium darin besteht, dass die Informationen noch nicht in Zusammenhang mit einem zum vertrauenswürdigen Modul gesendeten Datensatz verwendet wurden und/oder dass die Informationen einen Wert innerhalb eines vorgegebenen Wertebereichs aufweisen.
• Beispiel 30 ist das Datenverarbeitungssystem nach einem der Beispiele 21 bis 29, wobei die vertrauenswürdigen Module Sicherheitsdomänen sicherer Elemente sind.
• Beispiel 31 ist das Datenverarbeitungssystem nach einem der Beispiele 21 bis 30, welches ferner eine Datenerzeugungsvorrichtung umfasst, die dafür ausgelegt ist, das Zertifikat unter Verwendung des privaten Schlüssels zu erzeugen, den kryptographisch gesicherten Datensatz zu erzeugen und den Datensatz und das Zertifikat zur Vorrichtung zu senden, um die zusätzliche Autorisierung bereitzustellen.
• Beispiel 32 ist das Datenverarbeitungssystem nach Beispiel 31, wobei die Datenerzeugungsvorrichtung dafür ausgelegt ist, den kryptographisch gesicherten Datensatz zu erzeugen, das Zertifikat zu erzeugen und den Datensatz gemäß dem sicheren GlobalPlatform-Kanalprotokoll 11c zur Teilmenge zu senden.

Various examples are described below:

• Example 1 is a method of providing additional authorization to process a cryptographically secured data set for a subset of a group of trusted modules, such as with reference to FIG 14th described.
• Example 2 is the method according to Example 1, wherein each trustworthy module of the subset processes the data record if it successfully verifies the signature and the certificate.
• Example 3 is the method according to example 1 or 2, wherein each trustworthy module of the subset verifies the certificate by means of the modified public key.
• Example 4 is the method according to one of Examples 1 to 3, wherein for each trustworthy module of the subset, the modified public key or information on the basis of which the modified public key can be derived is sent by a message to the trustworthy module and the trustworthy module denotes the modified public key based on the message if it successfully verifies the signature.
• Example 5 is the method according to any one of Examples 1 to 4, wherein the original public key is a public key stored in the trusted modules of the group of trusted modules.
• Example 6 is the method according to Example 5, wherein the original public key was supplied to the group of trusted modules before the data record was generated.
• Example 7 is the method according to one of Examples 1 to 6, wherein the information on the basis of which the modified public key can be derived is sent and each trustworthy module of the subset derives the modified public key using the information.
• Example 8 is the method according to one of Examples 1 to 7, wherein the generation of the cryptographically secured data record is carried out by a first data processing component and the selection and transmission are carried out by a second data processing component and furthermore the cryptographically secured data record is carried out by the first data processing component of the second Data processing component is provided.
• Example 9 is the method according to Example 8, wherein the second data processing component also provides the cryptographic key for the signature to each of the trustworthy modules.
• Example 10 is the method according to any one of Examples 1 to 9, wherein the trusted modules are security domains of secure elements.
• Example 11 is the method according to one of Examples 1 to 10, wherein the cryptographically secured data record is generated, the certificate is generated and the data record is sent to the subset in accordance with the secure GlobalPlatform channel protocol 11c.
• Example 12 is the method according to one of Examples 1 to 11, the cryptographically secured data record comprising one or more commands and the one or more commands being executed when the data record is processed.
• Example 13 is the method of Example 12, wherein the one or more commands include a command to set a status of the trusted modules of the subset and / or a command to store a cryptographic key in the trusted modules of the subset.
• Example 14 is the method according to one of Examples 1 to 13, wherein the information on the basis of which the modified public key can be derived is sent and furthermore each trustworthy module of the subset checks whether the information meets a predetermined re-execution protection criterion, and the data only then processed if the information meets the predetermined re-execution protection criterion.
• Example 15 is the method according to Example 14, the specified re-execution protection criterion being that the information has not yet been used in connection with a data record sent to the trustworthy module and / or that the information has a value within a specified value range.
• Example 16 is the method of Examples 1-15, wherein the modified public key is sent to the subset and an additional signature is also sent for the modified public key and the additional signature is verified by each trusted module of the subset.
• Example 17 is an apparatus for providing additional authorization to process a cryptographically secured data set for a subset of a group of trusted modules, such as with reference to FIG 15th described.
• Example 18 is the device according to Example 17, the transmitter being designed to send the information from which the modified public key can be derived.
• Example 19 is the device according to example 17 or 18, wherein the one or more commands include a command to set a status of the trusted modules of the subset and / or a command to store a cryptographic key in the trusted modules of the subset.
• Example 20 is the device according to one of Examples 17 to 19, wherein the sender is designed to send the modified public key to the subset and an additional signature for the modified public key, which is to be verified by each trusted module of the subset send.
• Example 21 is a data processing system comprising the apparatus of any of Examples 17 to 20, further comprising one or more trusted modules of the subset, each trusted module being designed to verify the signature, verify the certificate and the data set to process.
• Example 22 is the data processing system of Example 21, with each trusted module of the subset being designed to process the data set if it successfully verifies the signature and certificate.
• Example 23 is the data processing system according to example 21 or 22, wherein the sender is designed to send the modified public key or information from which the modified public key can be derived for each trustworthy module of the subset by means of a message to the trustworthy module, and the trusted module is configured to determine the modified public key from the message if it successfully verifies the signature.
• Example 24 is the data processing system according to one of Examples 21 to 23, the cryptographically secured data record comprising one or more commands and the one or more commands being executed when the data record is processed. Example 25 is the data processing system according to one of Examples 21 to 24, wherein each trustworthy module of the subset is designed to verify the certificate by means of the modified public key.
• Example 26 is the data processing system according to any one of Examples 21 to 25, wherein the trusted modules of the subset are designed to store the original public key.
• Example 27 is the data processing system according to one of Examples 21 to 26, wherein the sender is designed to send the information from which the modified public key can be derived, and each trusted module of the subset is designed to send the modified public key using the information to derive.
• Example 28 is the data processing system according to one of Examples 21 to 27, wherein the sender is designed to send the information from which the modified public key can be derived, each trustworthy module of the subset is designed to check whether the information meet a predetermined re-execution protection criterion, and process the data only if the information meets the predetermined re-execution protection criterion.
• Example 29 is the data processing system according to one of Examples 21 to 28, wherein the specified re-execution protection criterion is that the information has not yet been used in connection with a data record sent to the trustworthy module and / or that the information has a value within a predetermined value range.
• Example 30 is the data processing system according to one of Examples 21 to 29, wherein the trusted modules are security domains of secure elements.
• Example 31 is the data processing system according to one of Examples 21 to 30, which further comprises a data generation device which is designed to generate the certificate using the private key, to generate the cryptographically secured data record and to send the data record and the certificate to the device to provide the additional authorization.
• Example 32 is the data processing system according to Example 31, wherein the data generation device is designed to generate the cryptographically secured data set, generate the certificate and send the data set according to the secure GlobalPlatform channel protocol 11c to the subset.

According to a further example, a method for supplying a command script (or generally a command sequence) to SEs is provided, wherein a command script is generated, a certificate for the command script using a secret key (SK.CA) derived from a secure reference key (SK.CA). CA '), using key derivation information (r) and using an algorithm that enables the generation of a public key (PK.CA') which is linked to the secret key (SK.CA ') using a public reference key (PK. CA), which is linked to the secret reference key (SK.CA), is generated, the key derivation information is sent to a group of SEs that are to receive the command script (for example securely), and the command script and the certificate are sent to the SE Group.

While specific embodiments have been illustrated and described herein, those skilled in the art will understand that a variety of alternative and / or equivalent implementations can be substituted for the specific embodiments shown and described without departing from the scope of the present invention. This application is intended to cover any adaptations or changes to the specific embodiments discussed herein. It is therefore intended that this invention be limited only by the claims and the equivalent embodiments.

List of reference symbols

100

safe element

101

Security domain

102

Data / key

103

Applet

104

Host

105, 106

Off-Card Entities (OCEs)

200

flow chart

201

OCE

202

third party

203

Security domain

204-208

Processing steps

300

flow chart

301

OCE

302

Certification Authority

303

Security domains

304-307

Processing steps

400

flow chart

401

OCE

402

Security domain

403

Host

404-407

Processing steps

500

flow chart

501

OCE

502

third party

503

Security domain

504-508

Processing steps

509.510

Authorizations

600

flow chart

601

OCE

602

third party

603

Security domain

604-608

Processing steps

609.610

Authorizations

700

flow chart

701

OCE

702

Security domain

703

attacker

704-707

Processing steps

800

flow chart

801

OCE

802

Certification Authority

803

Security domain

804-807

Processing steps

900

flow chart

901

OCE

902

Certification Authority

903

Security domains

904

third party

905

Processing steps

1000

flow chart

1001

OCE

1002

Certification Authority

1003

third party

1004

Security domains

1005

Host

1006-1013

Processing steps

1100

flow chart

1101

OCE

1102

Certification Authority

1103-1105

Scripts

1106-1108

Processing steps

1200

flow chart

1201

OCE

1202

Certification Authority

1203

third party

1204

Security domains

1205

Host

1206-1213

Processing steps

1300

flow chart

1301

OCE

1302

Certification Authority

1303-1308

Processing steps

1400

flow chart

1401-1405

Processing steps

1500

Authorization device

1501

receiver

1502

Voters

1503

Channel

Claims (19)

Method for providing an additional authorization for the processing of a cryptographically secured data record for a subset of a group of trustworthy modules, comprising the following: Generating a certificate of a key pair using a modified private key, the modified private key being a modification of an originally configured private key that is linked to an original public key, Generating a cryptographically secured data record using the key pair, Selecting a subset of trusted modules from the group of trusted modules to which the data set is to be sent, Sending the dataset, the certificate and a modified public key associated with the modified private key, or information that can be used to derive the modified public key from the original public key, to the subset and sending a signature created by a for the subset of the group of trusted modules depends on the cryptographic key generated for each trusted module of the subset, the signature being a signature of the modified public key and / or of the information from which the modified public key can be derived, and Verification of the signature, verification of the certificate and processing of the data set by each trustworthy module of the subset. Procedure according to Claim 1 where each trusted module of the subset processes the data set if it successfully verifies the signature and certificate. Procedure according to Claim 1 or 2 , each trusted module of the subset verifying the certificate by the modified public key. Method according to one of the Claims 1 to 3 For each trusted module of the subset, the modified public key or information from which the modified public key can be derived is sent by a message to the trusted module and the trusted module determines the modified public key based on the message, if it has the signature successfully verified. Method according to one of the Claims 1 to 4th where the original public key is a public key stored in the trusted modules of the trusted module group. Procedure according to Claim 5 , the original public key being supplied to the group of trusted modules prior to the creation of the data set. Method according to one of the Claims 1 to 6th wherein the information from which the modified public key can be derived is sent and each trusted module of the subset derives the modified public key using the information. Method according to one of the Claims 1 to 7th wherein the generation of the cryptographically secured data record is carried out by a first data processing component and the selection and the transmission are carried out by a second data processing component and furthermore the cryptographically secured data record is provided by the first data processing component of the second data processing component. Procedure according to Claim 8 wherein the second data processing component also provides the cryptographic key for the signature to each of the trustworthy modules. Method according to one of the Claims 1 to 9 , where the trusted modules are security domains of secure elements. Method according to one of the Claims 1 to 10 , wherein the cryptographically secured data record is generated, the certificate is generated and the data record is sent to the subset according to the secure GlobalPlatform channel protocol 11c. Method according to one of the Claims 1 to 11 wherein the cryptographically secured data record comprises one or more commands and the one or more commands are executed when the data record is processed. Procedure according to Claim 12 wherein the one or more commands include a command to set a status of the trusted modules of the subset and / or a command to store a cryptographic key in the trusted modules of the subset. Method according to one of the Claims 1 to 13th , wherein the information on the basis of which the modified public key can be derived is sent and furthermore each trustworthy module of the subset checks whether the information meets a given re-execution protection criterion, and the data is only processed if the information fulfills the given re-execution protection criterion. Procedure according to Claim 14 , wherein the predetermined re-execution protection criterion consists in the fact that the information has not yet been used in connection with a data record sent to the trustworthy module and / or that the information has a value within a predetermined value range. Method according to one of the Claims 1 to 15th wherein the modified public key is sent to the subset and further an additional signature is sent for the modified public key and the additional signature is verified by each trusted module of the subset. Device for providing an additional authorization for the processing of a cryptographically secured data record for a subset of a group of trustworthy modules, which comprises the following: a receiver which is designed to receive a cryptographically secured data record and a certificate of a key pair used to secure the generated data record using a modified private key, the modified private key being a modification of an originally configured private key in connection with an original public key Key is a selector which is designed to select a subset of trustworthy modules from the group of trustworthy modules to which the data set is to be supplied, and a sender that is designed to send the data set, the certificate and the modified public key associated with the modified private key or information from which the modified public key can be derived from the original public key to the subset and for to send each trusted module of the subset a signature that is dependent on a cryptographic key that was generated for the subset of the group of trusted modules, the signature being a signature of the modified public key and / or the information on the basis of which the modified public key is derived can is. Data processing system that the device according to Claim 17 further comprising one or more trusted modules of the subset, each trusted module configured to verify the signature, verify the certificate, and process the data set. Data processing system according to Claim 18 which further comprises a data generation device configured to generate the certificate using the private key, generate the cryptographically secured data record and send the data record and the certificate to the device in order to provide the additional authorization.

Images