Device Security Rating Documentation

• 1: Concepts
• 1.1: Device Management Service (GMS)
• 1.2: Policy Enforcement Point & Policy Decision Point
• 1.3: Policy Information Point & Policy Administration Point
• 1.4: Trust Client
• 2: Requests for Comments
• 2.1: DSR-RFC-01 Device Registration
• 2.2: DSR-RFC-02 Resource Access
• 2.2.1: nginx Deployment
• 2.3: DSR-RFC-03 Device Deletion
• 2.4: DSR-RFC-04 Security Tokens
• 2.5: DSR-RFC-05 UI Flows
• 2.6: DSR-RFC-06 Device Security Attributes
• 2.7: DSR-RFC-09 Health Service API
• 2.8: DSR-RFC-11 Mobile Vulnerability Management
• 3: Limitations
• 4:

1 - Concepts

1.1 - Device Management Service (GMS)

The Device Security Rating enables the registration, authentication and removal of devices of users to access TI resources. These functionalities are realized by the by the Device Management Service (GMS). A device in this context is the specific instance of an app running on a device on which the TrustClient runs for secure access to the TI. A binding of the registered device to the registering user is taken into account. Examples are the registration of a device by an insured person or the registration of a health service or proxy server by a medical facility. Attacks on TI services from unregistered end devices can be limited from the outset. In addition, the user connection can be checked for access to TI services.

Depending on the requirements of the health service, access can, for example, be restricted to devices that are registered for the authenticated user only. Access from devices from medical facilities could be enabled for all registered user roles (e.g., doctor, nurse, healthcare professional, …). The Device Management Service (GMS) uses the device token to provide information about the authenticated device and its execution environment to services.

Architecture and Deployment

1.2 - Policy Enforcement Point & Policy Decision Point

Policy Enforcement Point (PEP)

Access to Health Services is only possible after successful authorization. The Policy Enforcement Point enforces this for each individual access to a Health Services, allows authorized access in the granularity of the Zero Trust resources and protects against unauthorized access. For this purpose, it passes the user, device and environment information provided by the Trust Client to the Policy Enforcement Point during initial authorization and expects the Policy Enforcement Point to make an access decision. The Policy Enforcement Point also provides anonymized information on access decisions and pre-processed information on suspicious access requests for monitoring purposes.

Policy Decision Point (PDP)

The core of a Zero Trust architecture is the decision as to whether a specific user may access a specific resource at a specific time, taking into account the available information on the user, device and environment. The architecture provides a Policy Decision Point for each Health Services that makes this decision. This requires up-to-date and explicit guidelines that define how authenticated users, services, devices and applications may interact with each other. A Policy Decision Point therefore receives the currently valid set of rules for the relevant specialist service from the Policy Administration Point, determines the rules that apply to the current access and evaluates them. To do this, the Policy Decision Point determines all the information required for the evaluation, unless it is already provided by the client with the authorization request. The concept follows the Enterprise-Centric-Implementation-Model according to ISO/IEC 29146 regarding the realization of Policy Decision Point and Policy Enforcement Point and provides for both components within a common trust space. This can be realized by a common boundary around the specialist service and Policy Enforcement Point/Policy Decision Point or as separate instances (e.g. IaaS components) that are coupled in a trustworthy manner.

Realisation of PDP with Open Policy Agent

The PDP in DSR has been implemented using Open Policy Agent (OPA). On the one hand, the architecture of OPA offers numerous flexible integration scenarios (SDK, microservice, proxy); on the other hand, the policy bundles and external data can be well separated. The latter gives us great flexibility in the design and distribution of policies:

Logical policy expressions are distributed as versioned bundles via the “policy as code” approach. Additional data necessary for the access decision can be updated separately and thus decoupled in time. This separation allows additional assurance that only tested bundles are installed in production, while dynamic external data can be updated at runtime. OPA supports different strategies for updating external data, see https://www.openpolicyagent.org/docs/latest/external-data/.

DSR Policy

The DSR policy consists of a list of policy rules that are dynamically evaluated for each request by the PDP. The policy is structured into different modules. This enables policy authors and domain experts to focus on specific parts of the policy. The modules are then compiled together for deployment and are provided as one policy file in form of an OPA bundle to the PDP.

The following policy modules are available:

• Device policy
  • Android
  • iOS
• Security policy

Note: Since the DSR Project ist not integrated into a real IDP, there is no user policy.

The device policy contains minimum requirements for users’ devices before server access if allowed. Apple App Attest, Google Key & ID Attestation as well as Google Play Integrity attestation services provide different information in their attestation results – this means that different information can be verified in the policy:

• Name and version of the app (Android and iOS)
• Device model (Android and iOS)
• Minimum OS Version (Android and iOS) and security patch level (Android only)
• Attestation security level (Android only)
• Password complexity (Android only) The security policy is used to identify access from banned IP address, countries or from banned users.

Policy Structure

Policies habe been broken down into two seperate files. The policy file itself (available in the PAP) and the corresponding data file (PIP Data). This decision was taken with the idea that the policy file is relative static but the data file contains much more dynamic information that has to be updated reguraly.

Policy Distribution

1. Policy bundles are created and signed via a CI/CD pipeline.
2. Bundles are published via the Bundles Registry. OPA supports OCI or plain HTTPS for this purpose.
3. The service provider replicates the policies from the bundles HTTP server to their local environment.
4. The service administrator needs to ensure that the PDP/PEP receives the necessary policy bundles.

1.3 - Policy Information Point & Policy Administration Point

Policy Information Point (PIP)

Contextual information is required to evaluate individual rules of the Zero Trust architecture. In addition to the Ìdentity Provider, the Device Management Service (GMS) and the Trust Client, this information is provided by Policy Information Points. Policy Information Points can provide information centrally for all services (cross-service Policy Information Point) or provide local information for rule evaluation for a specialist service (specialist service-specific Policy Information Point). An example of the first case is information about secure device models, which can be included in the evaluation of device security and thus in the access decision. Policy Information Points can also be filled with current information from the comprehensive monitoring. In this way, access decisions can be made dynamically based on current information at the time of access.

Policy Administration Point (PAP)

The rules of a Zero Trust architecture must be created, configured, tested and managed. This function is performed by the Policy Administration Point. The set of rules managed via the Policy Administration Point enables attribute-based access control (ABAC). This allows different access requirements to be implemented for different roles, such as service providers or insured persons with different requirements for their end devices and environment.

1.4 - Trust Client

The Trust Client is the central component for communication and interaction with the TI Zero Architecture (ZTA) and must provide the following functionality:

• generation, storage and verification of a cryptographic, hardware-bound app/device identity
• generation and verification of device and app attestations using platform mechanisms and trusted third parties
• establishment of a mutually authenticated, confidential communication channel with authorized participants of the TI (over mTLS)
• management of registered apps and devices as a front-end of the GMS

With a focus on mobile devices, the Trust Client can be implemented in different ways as part of a (mobile) application:

• as part of the business logic
• encapsulated module or (native) library / SDK
• encapsulated module or (native) library / SDK from a third-party provider

Logical Components

App / Device Identity

Prior to the first use, an app accessing a service in the TI ZTA must be registered at the GMS. The app identity created during this process (cryptographic, hardware-bound key pair with associated certificate issued by GMS CA) is assigned to a user account (e.g., insured person, healthcare professional) by authenticating with the electronic health card or health ID. The app identity is used by the app via the Trust Client in the future to authenticate itself to authorized third parties in the TI (during connection establishment of the mTLS communication channel).

The Trust Client is responsible for generating, storing and verifying the cryptographic, hardware-bound app identity and uses hardware-based security mechanisms of the respective platform (Android, iOS) for implementation:

Android

• cryptographic, hardware-bound key pair (keypair_mTLS):
  • ECC key pair with NIST P-256 curve
  • in TEE or Strongbox KeyStore, app-bound
  • proof of storage location / properties via Android Key & ID Attestation (via app-specific app attestation key material)

iOS

• cryptographic, hardware-bound key pair (keypair_mTLS):
  • ECC key pair with NIST P-256 curve
  • in the Secure Enclave, app-bound
  • indirect proof of storage location / properties via Apple App Attest API (pubkey_mTLS as fingerprint in the App Attest API attestation challenge)

To prove the app identity to third parties, an X.509 client certificate is generated in a further step for the key material created under Android and iOS (keypair_mTLS). This can be done in two ways:

• self-signed client certificate
• client certificate issued by a GMS CA

Device and App Attestation

In addition to the app identity, the device’s and application’s health (Zero Trust signals) are taken into account when making an access to a resource at the PDP/PEP. The trustworthy collection of the health signals is carried out using platform-specific attestation and collection mechanisms (see Apple Platform Security Guide, Android Platform Security Model) in the TrustClient in order to guarantee the authenticity and integrity of the signals. As there is currently no standardized, cross-platform attestation format, the platform-specific attestations are converted into a consolidated device token by the GMS after checking their integrity and authenticity.

Android

Google Play Integrity API

The Play Integrity API can be used to attest the trustworthiness (integrity, authenticity) of an Android device, the Play Framework running on it and the application accessing it. The attestation is carried out after triggering an API call and made available for verification by authorized parties in form of an integrity verdict (JWT token). The verification of integrity verdicts by an authorized party (usually app developers) can be carried out remotely by sending the verdict to Google or after downloading the key material required to decrypt the verdict locally. Due to the simplicity of the attestation information provided by the Play Integrity API, it is very well suited as a low-threshold attestation. From Android 9 onwards, the actual attestation on the end device is supported by hardware security mechanisms (Android Key & ID Attestation) and is therefore of a higher assurance. Google Play Services must be installed on the Android device for the attestation process.

The Play Integrity API is used by the TrustClient to prove the general trustworthiness of the end device, the Play Services and the app to the GMS.

Android Key & ID Attestation

Key Attestation can be used to attest properties and the storage location (software, Trusted Execution Environment (TEE), Strongbox/TRH) of cryptographic key material generated in the Android KeyStore. Additionally, ID attestation can be used to attest the properties of a device at the time of key material generation. The actual attestation of the key material and the device properties is carried out from the TEE/TRH of a device and is signed with a platform attestation group key and certificate (Android 7 - 11) securely deployed into the device during the manufacturing. From Android 13 onwards, this group key is replaced by short-lived, app-specific attestation keys.

If an app generates cryptographic key material in the KeyStore, a X.509 attestation certificate is created and signed with the platform attestation group key. In addition, further device properties are stored in the key attestation extension data schema of the certificate before the signature is created. The X.509 certificate can now be used by third parties to check whether the key material originates from a genuine end device, in which key store it is stored and what state the end device is in.

An app-specific attestation key pair (keypair_attest) is created by the TrustClient and attested using Key & ID Attestation. Keypair_attest and the corresponding attestCert_attest now serve as the root of trust for the Trust Client, i.e. attests/signs all other cryptographic keys created in the life cycle of the Trust Client and surrounding app. This includes the app identity (keypair_mTLS, cert_mTLS), but also device and app attestations requested during resource access (keypair_attestation_n, cert_attestation_n).

Further Device Signals

In addition to the device signals from Play Integrity API and Key & ID Attestation, Android System API calls can be used to collect further valuable properties of a device. This information is is collected in the application during runtime. For more information see DSR-RFC-06 or Android Zero Trust Signals.

iOS

With App Attest, part of the DeviceCheck framework, Apple provides a native API that makes it possible to verify the authenticity and integrity of Apple devices and apps via a hardware-bound key pair and an associated attestation or assertion in accordance with the W3C WebAuthn specification. In contrast to Android Key & ID Attestation, this key pair can only be used to sign challenges.

Further Device Signals

Similar to Android , there are further valuable device and app properties that can be collected by using additional system APIs. For more information see DSR-RFC-06.

Communication Channels

Trust Client to GMS

The Trust Client communicates directly or via the surrounding app with the GMS. In either case, the Trust Client provides the cryptographic key material required for secure communication (TLS, mTLS), including the attestation and session tokens:

• App registration: When initial contact is made with the GMS, no app identity or key material for mTLS client authentication yet exists in the Trust Client. The GMS therefore offers a standard TLS endpoint for registration.
• App attestation & device management: After successful registration with the GMS, the Trust Client holds key material for mTLS client authentication (keypair_mTLS). All GMS endpoints outside the registration are therefore only available via mTLS.

Trust Client to Health Service

The Trust Client communicates directly or via thesurrounding app with the health service. In either case, the Trust Client provides the cryptographic key material required for secure communication (mTLS).

2 - Requests for Comments

2.1 - DSR-RFC-01 Device Registration

Device registration is performed by the user after previous authentication.

1. High Level Flow

1. At first start, the TrustClient generates the app/device identity key material and a corresponding Certificate Signing Request.
2. The TrustClient then triggers the attestation of the key material, device and app with the help of the Platform Attestation Service and receives attestation results.
3. To register the device for themself, the user signs a Device Registration Token, containing the app/device identity and attestation results and the Certificate Signing Request with their electronic health card (EF.C.CH.AUT.E256). Then the TrustClient sends the Device Registration Token to the Device Management Service (GMS).
4. With the help of the Platform Attestation Service, the Device Management Service (GMS) verifies the received attestations and key material.
5. The Device Management Service (GMS) sends the Certificate Signing Request to the GMS CA which then issues a Trust Client Certificate
6. Finally, the Device Management Service (GMS) stores the app/device identity key material with the corresponding user identity in its database.
7. The Device Management Service (GMS) sents the Trust Client Certificate to the TrustClient.

2. Flow Details

@startuml DSR-RFC-01 Main Flow
autonumber "<b>[00]"
skinparam defaultFontSize 10
skinparam defaultFontName Helvetica
skinparam DefaultMonospacedFontName Courier
skinparam lengthAdjust none

participant TrustClient

participant Smartcard

participant GMS

activate TrustClient

TrustClient -> GMS ++: get ""nonce""
note right
Regular TLS
Server auth only
end note

GMS -> GMS: generate ""nonce""\n store ""nonce""
GMS -> TrustClient: return ""nonce""

TrustClient -> TrustClient: derive nonces\n\t""nonce_keypair_mTLS = SHA256(nonce | 'KEYPAIR_MTLS')""\n\t""nonce_CSR_mTLS = SHA256(nonce | 'CSR_MTLS')""\n\t""nonce_Integrity = SHA256(nonce | 'INTEGRITY')""\n\t""nonce_smartcard = SHA256(nonce | 'SMARTCARD')""\n\t""nonce_attest = SHA256(nonce | 'ATTEST')""

alt#FEFFD5  2.1.1 Create Android Device Registration
TrustClient -> TrustClient: generate key pair and\ncreate ""JWT_registration""
else 2.2.1 Create Apple Device Registration 
TrustClient -> TrustClient: generate key pair and\ncreate ""JWT_registration""
end

TrustClient -> Smartcard ++:  sign ""(JWT_registration, nonce_smartcard)""\n\twith ""PrK.CH.AUT.E256""/""EF.C.CH.AUT.E256""
return return JWS_registration_signed


TrustClient -> GMS: register device JWS(JWS_registration_signed)

GMS -> GMS: verify JWS_registration_signed
GMS -> GMS: check EF.C.CH.AUT.E256 validity
note left
gematik PKI OCSP
end note

alt#FEFFD5 2.1.2 Verify Android Device Registration 
GMS -> GMS: verify ""JWS_registration_signed""\nextract Android specifics
else 2.2.2 Verify Apple Device Registration
GMS -> GMS: verify ""JWS_registration_signed""\nextract Apple specifics
end


GMS -> GMS: extract KVNR from EF.C.CH.AUT.E256\nin JWS_registration_signed
GMS -> GMS: create cert_mTLS(CSR, UUID_device, nonce)

alt#FEFFD5 Store Android Device Registration
GMS -> GMS: store\n\tKVNR\n\tUUID_device\n\tcert_mTLS\n\tcert_attest
else Store Apple Device Registration
GMS -> GMS: store\n\tKVNR\n\tUUID_device\n\tcert_mTLS\n\tattestation_statement
end 
return return cert_mTLS
TrustClient -> TrustClient: store cert_mTLS

@enduml

2.1 Android specifics

2.1.1 Create Android Device Registration

@startuml
autonumber "<b>['2.1.1' 00]"
skinparam defaultFontSize 10
skinparam DefaultMonospacedFontName Courier
skinparam lengthAdjust none

activate TrustClient
participant PlayIntegrityAPI


group Android
TrustClient -> TrustClient: generate\n\t""keypair_attest""\n\t""attestCertChain(nonce_attest)""\n\t""keypair_mTLS""\n\t""keypair_mTLS_cert(nonce_keypair_mTLS)""\n\t""CSR(nonce_CSR_mTLS, keypair_mTLS)""
TrustClient -> PlayIntegrityAPI ++: perform IntegrityTokenRequest(nonce_Integrity)
return return integrityVerdict

TrustClient -> TrustClient: create\n\t""JWT_registration(""\n\t\t""TYPE_ANDROID,""\n\t\t""nonce,""\n\t\t""pubkey_mTLS,""\n\t\t""keypair_mTLS_cert,""\n\t\t""pubkey_attest,""\n\t\t""attestCertChain""\n\t\t""integrityVerdict,""\n\t\t""CSR""\n\t"")""

end

@enduml

2.1.2 Verify Android Device Registration

@startuml
autonumber "<b>['2.1.1' 00]"
skinparam defaultFontSize 10
skinparam DefaultMonospacedFontName Courier
skinparam lengthAdjust none

activate GMS
participant GoogleServer


group Android
GMS -> GMS: extract nonce, pubkey_mTLS, AttestCert_mTLS,\nintegrityVerdict, CSR from JWS_registration_signed
GMS -> GMS: verify attestCertChain and certification extension data
GMS -> GMS: verify AttestCert_mTLS and certification extension data
GMS -> GMS: verify AttestCert_mTLS was signed by pubkey_attest
GMS -> GoogleServer ++: get Key Attestation certificate revocation status list

return return CRL_json
GMS -> GMS: evaluate CRL_json
GMS -> GoogleServer ++: request integrity_verdict(integrityVerdict)
return return verdict_json
GMS -> GMS: evaluate verdict_json

end

@enduml

2.2 Apple specifics

2.2.1 Create Apple Device Registration

@startuml
autonumber "<b>['2.2.1' 00]"
skinparam defaultFontSize 10
skinparam DefaultMonospacedFontName Courier
skinparam lengthAdjust none

activate TrustClient
participant AppAttestAPI

group Apple
TrustClient -> TrustClient: generate\n\t""keypair_mTLS""\n\t""CSR(nonce_CSR_mTLS, keypair_mTLS)""
TrustClient -> AppAttestAPI ++: generate\n\t""keypair_attest(""\n\t\t""SHA256(nonce_Integrity | SHA256(pubkey_mTLS))""\n\t"")""
AppAttestAPI -> AppAttestAPI: attest

return return attestation_statement

TrustClient -> TrustClient: create\n\t""JWT_registration(""\n\t\t""TYPE_IOS,"",\n\t\t""nonce,""\n\t\t""pubkey_mTLS,""\n\t\t""attestation_statement,""\n\t\t""keyIdentifier_attest,""\n\t\t""CSR""\n\t"")""

end

@enduml

2.2.2 Verify Apple Device Registration

@startuml
autonumber "<b>['2.2.2' 00]"
skinparam defaultFontSize 10
skinparam DefaultMonospacedFontName Courier
skinparam lengthAdjust none

activate GMS


group Apple
GMS -> GMS: extract nonce, pubkey_mTLS, attestation_statement,\nkeyIdentifier_attest, CSR
GMS -> GMS: verify attestation_statement
end

@enduml

2.2 - DSR-RFC-02 Resource Access

Resource access can only be performed from the previously registered and fresh attested device.

1. High Level Flow

1. Policy Decision Point regularly downloads, verifies, and installs the currently active policy from Policy Administration Point as well as context information from Policy Information Point.
2. TrustClient requests an attestation from the platform APIs.
3. Attestation results are transmitted to Device Management Service (GMS) in form of Device Attestation Token. Device Registration Service verifies the authenticity and integrity of the attestation and issues the Device Token
4. TrustClient connects to the eHealth Service using TLS. Mutual authentication is performed using the client certificate issued in DSR-RFC-01
5. Trust Clientsends the Device Token as bearer token bound to mTLS certificate or a OAuth2 Code to the eHealth Service’s PEP. PEP verifies the authenticity of the Device Token and extracts the device information.
6. PEP uses device information and other available signals (e.g. HTTP request headers) as input to the PDP. PDP applies the policy against the device information and any other input provided to it by the PEP.
7. Once PDP allowed the access by making the positive decision, the PEP lets the eHealth Service to continue and provide resources and other functionalities to the client.

2. Flow Details

@startuml DSR-RFC-02 Main Flow
autonumber "<b>[00]"
skinparam defaultFontSize 10
skinparam defaultFontName Helvetica
skinparam DefaultMonospacedFontName Courier
skinparam lengthAdjust none

activate TrustClient

participant GMS
box "Policy Enforcement"
participant PEP
participant PDP
end box
participant Backend as "eHealth\nService"

TrustClient -> GMS++: ""GET /nonce""
note right
Regular TLS
Server auth only
end note
GMS -> GMS: generate ""nonce""\nstore ""nonce"" in session
GMS -> TrustClient --: ""nonce""


TrustClient -> TrustClient: generate\n  ""pkceCodeVerifier""\n  ""pkceCodeChallenge""

alt#FEFFD5  2.1.1 Create Android Device Attest
TrustClient -> TrustClient: Provide JWS_attest_signed 
else 2.2.1 Create Apple Device Attest 
TrustClient -> TrustClient: Provide JWS_attest_signed 
end


TrustClient -> GMS ++ : ""JWS_attest_signed"" \n ""pkceCodeChallenge""  
note right
Mutual TLS
end note
GMS -> GMS: check if device ID is known\n(find device registration)
GMS -> GMS: check if publicKey fingerprint from mTLS is\n"sub" claim at JWS_attest_signed
GMS -> GMS: verify JWS_attest_signed  
GMS -> TrustClient: return auth_code

alt#FEFFD5 2.1.2 Verify Android Device Attest 
GMS -> GMS: Provide device_token 
else 2.2.2 Verify Apple Device Attest
GMS -> GMS: Provide device_token 
end

GMS -> GMS: sign device_token(privKey_GMS)
 
 ... some delay ...
 
TrustClient -> GMS: ""auth_code""\n""pkceCodeVerifier""
note right
Mutual TLS
end note
GMS -> GMS: verify\n ""auth_code""\n ""pkceCodeVerifier""
return ""device_token""
note right
PKCE can also be performed by PEP
end note

TrustClient -> PEP ++: request resource(""device_token"")
hnote over PEP: authenticate user
PEP -> PEP: verify ""device_token""
PEP -> PEP: create \n""policy_decision_input""

PEP -> PDP: request \n""policy_decision""
PDP -> PEP: ""policy_decision""

Backend -[#8BC34A]> TrustClient: <font color="#8BC34A"><&circle-check*4.0>
   

/'
group Android
TrustClient -> TrustClient: trigger Play Integrity API(nonce_PlayIntegrityAPI),\n\tcreate keypair keypair_attest_derived(pubkey_mTLS),\n\tAttestCert_derived(nonce_attest_derived),\n\tcollect device_attributes_security
TrustClient -> TrustClient: create JWT_attest(\n\tTYPE_ANDROID,\n\tintegrity_verdict,\n\tAttestCert_derived,\n\tdevice_attributes_security,\n\tnonce)
TrustClient -> TrustClient: sign JWT_attest with keypair_attest_derived
end Android

group Apple
TrustClient -> TrustClient: trigger AppAttestAPI assertion(\n\tnonce_attest_derived | fingerprint(pubkey_mTLS)\n),\ncollect device_attributes_security
TrustClient -> TrustClient: create JWT_attest(\n\tTYPE_iOS,\n\tassertion,\n\tdevice_attributes_security,\n\tnonce)
TrustClient -> TrustClient: sign JWT_attest with keypair_attest_sign
end Apple
'/

@enduml

2.1 Android specifics

2.1.1 Create Android Device Attest

@startuml
autonumber "<b>['2.1.1' 00]"
skinparam defaultFontSize 10
skinparam DefaultMonospacedFontName Courier
skinparam lengthAdjust none

activate TrustClient

group Android
TrustClient -> TrustClient: trigger Play Integrity API(nonce_PlayIntegrityAPI),\n\tcreate keypair keypair_attest_derived(pubkey_mTLS),\n\tAttestCert_derived(nonce_attest_derived),\n\tcollect device_attributes_security
TrustClient -> TrustClient: create JWT_attest(\n\tTYPE_ANDROID,\n\tintegrity_verdict,\n\tAttestCert_derived,\n\tdevice_attributes_security,\n\tnonce)
TrustClient -> TrustClient: sign JWT_attest with keypair_attest_derived
end

2.1.2 Verify Android Device Attest

@startuml
autonumber "<b>['2.1.2' 00]"
skinparam defaultFontSize 10
skinparam DefaultMonospacedFontName Courier
skinparam lengthAdjust none

activate GMS

group Android
GMS -> GMS: extract\n\t""integrity_verdict""\n\t""AttestCert_derived""\n\t""device_attributes_security""
GMS -> GMS: verify\n\t""AttestCert_derived""\ncheck\n\t""AttestCert_derived is child""\n\t""of AttestCert_mTLS""
GMS -> GoogleServer ++: request\n\t""integrity_verdict(integrity_verdict)""
return return ""verdict_json""
GMS -> GMS: create\n\t""device_token(""\n\t""verdict_json,""\n\t""device_attributes_security,""\n\t""UUID_device <-> KVNR""\n\t"")""

end

2.2 Apple specifics

2.2.1 Create Apple Device Attest

@startuml
autonumber "<b>['2.2.1' 00]"
skinparam defaultFontSize 10
skinparam DefaultMonospacedFontName Courier
skinparam lengthAdjust none

activate TrustClient

group Apple
TrustClient -> TrustClient: trigger AppAttestAPI assertion(\n\tnonce_attest_derived | fingerprint(pubkey_mTLS)\n),\ncollect device_attributes_security
TrustClient -> TrustClient: create JWT_attest(\n\tTYPE_iOS,\n\tassertion,\n\tdevice_attributes_security,\n\tnonce)
TrustClient -> TrustClient: sign JWT_attest with keypair_attest_sign
end

2.2.2 Verify Apple Device Attest

@startuml
autonumber "<b>['2.2.2' 00]"
skinparam defaultFontSize 10
skinparam DefaultMonospacedFontName Courier
skinparam lengthAdjust none

activate GMS

group Apple
GMS -> GMS: extract assertion, device_attributes_security
GMS -> AppleCA ++ : verify assertion
return return result
group optional
  GMS -> AppleBackEnd ++: assess fraud risk
  return return assessment
end optional
GMS -> GMS: create device_token(\n\tassertion,\n\tdevice_attributes_security,\n\tUUID_device <-> KVNR\n)

end

2.2.1 - nginx Deployment

Using nginx as frontend proxy with subrequest

In our sample implementation we use nginx as frontend proxy. Each request is authorized using the auth_request subrequest, which is handled by the PEP. If PEP returns any other response as 200, the proxy access to the business backend will be denied by the nginx.

autonumber "<b>[0]"
skinparam defaultFontSize 10
skinparam defaultFontName Helvetica
skinparam DefaultMonospacedFontName Courier
skinparam lengthAdjust none

activate Frontend

box "Policy Enforcement"
participant "nginx" as Proxy
participant "dsr-pep" as PEP #Orange
end box

participant "dsr-fahdienst" as Backend

group Unauthorized
Frontend -> Proxy ++: ""GET /resource""
Proxy -> PEP ++: auth subrequest\n""GET /.../auth_request""
PEP -> PEP: missing token\nor session expired
PEP -> Proxy --: ""401 Unauthorized""\n""WWW-Authenticate: ...""
Proxy -> Frontend --: ""401 Unauthorized""\n""WWW-Authenticate: ...""
end

group Authorized
Frontend -> Proxy ++: ""GET /resource""\n""Authorization: Bearer {access_token}""
Proxy -> PEP ++: auth subrequest\n""GET /.../auth_request""
PEP -> PEP: ""access_token"" is valid
PEP -> Proxy --: ""200 OK""
Proxy -> Backend ++: ""proxy_pass GET /resource""
Backend -> Proxy --: Resource
Proxy -> Frontend --: Resource
end


deactivate Frontend 

2.3 - DSR-RFC-03 Device Deletion

User can delete a device from any previously registered device.

Flow Details

@startuml DSR-RFC-03 Main Flow 
autonumber "<b>[00]"

actor User as User

User -> FrontEnd: view devices
FrontEnd -> TrustClient: request devices

TrustClient --> GMS++: establish mTLS channel (cert_mTLS)
TrustClient -> GMS: GET ""/device-registrations""\n\t""userIdentifier={KVNR}""
GMS -> TrustClient: array ""DeviceRegistration""
TrustClient -> FrontEnd: devices list
FrontEnd -> User: show devices
User -> FrontEnd: delete device_X
FrontEnd -> TrustClient: delete device_X
TrustClient --> GMS: DELETE ""/device-registrations""\n\t""userIdentifier={KVNR}""\n\t""deviceIdentifier={device_X}""
GMS --> TrustClient--: 200 OK
TrustClient -> FrontEnd: deleted successfully
FrontEnd -> User: show remaining devices

@enduml

2.4 - DSR-RFC-04 Security Tokens

DSR utilizes several tokens in order to register and attest the devices. All tokens are implemented using JSON Web Token (JWT).

Device Registration Token (JWT_registration)

• sent from TrustClient to Device Management Service (GMS) during registration
• contains all needed information for registration
• signed with EF.C.CH.AUT.E256 (eGK)
• see DSR-RFC-01 for corresponding sequence diagram

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

// header
{
  "typ": "JWT",
  "alg": "BP256R1",
  "x5c": [
    "<EF.C.CH.AUT.E256>",
    "<intermediates_n>" //see RFC-7515, 4.1.6 String | Base64 encode DER Cert
  ]
} 
 
// body (Android)
{
  "iss": "TrustSDK_<SDKVersion>",
  "sub": "<pubkey_mTLS_fingerprint (SHA256)>",
  "subjectCert": "<cert>" (attested by attestKeyPair) // base64 encoded
  "iat": <NumericDate>,
  "type": "android",
  "nonce": "<String>", // base64 encoded bytes
  "csr": "<csr>", // base64 encoded PKCS#10
  "attestPulicKey": "<pubkey_attest_fingerprint (SHA256)>",
  "attestCertChain": [
    "<leaf cert>",
    "<intermediate cert>",
    "<...>"
  ], // base64 encoded der certs
  "integrityVerdict": "<Sring>", //encrypted integrity verdict exact from google response
  "packageName": "..."
}  
 
// body (Apple)
{
  "iss": "TrustSDK_<SDKVersion>", // String
  "sub": "<pubkey_mTLS_fingerprint (SHA256)>", // String | Base64 encoded sha256
  "iat": <NumericDate>, // int
  "type": "apple", // String
  "nonce": "<nonce>", // String | Base64 encoded binary data
  "csr": "<csr>", // String | Base64 encoded PKCS#10
  "keyId": "<keyIdentifier>", //String | Base64 encoded binary data - for attestation required key identifier
  "attestation": "<attestationObject>" // String | Base64 encoded CBOR
}    
 
// signature
{..}

Device Attestation Token (JWT_attest)

• sent from TrustClient to Device Management Service (GMS) for attestation
• contains attestation information
• signed with mTLS_privateKey, (Android), privateKey_attest (iOS)
• see DSR-RFC-02 for corresponding sequence diagram

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

// header
{
  "typ": "JWT",
  "alg": "ES256", // NIST P-256,
  "x5c": [
    "<cert_mTLS>",
    "<intermediate_1>",
    "<intermediate_n>" //see RFC-7515, 4.1.6>
  ]
}
 
// body (Android)
{
  "iss": "TrustSDK_<SDKVersion>", // String
  "sub": "<String>", // Base64 encoded sha256 pubkey_mTLS_fingerprint (SHA256)
  "iat": <NumericDate>,
  "type": "android",   "nonce": "<String>", // base64 encoded bytes
  "attestationCertChain": [
    "<attestation_cert>",
    "<attest_cert_1>",
    "<attest_cert_n>",
    "<..>"
  ], // base64 encoded der certs (fresh generated attestationCert + attestCertChain)
  "integrityVerdict": "<String>", //encrypted integrity verdict exact from google response
  "packageName": "<String>",
  "deviceAttributes": { //see DSR-RFC-06
    "build": {
      "version": {
        "sdkInit": "<int>", // Build.VERSION.SDK_INIT,
        "securityPatch": "<String>" // Build.VERSION.SECURITY_PATCH
      },
      "manufacturer": "<String>",
      "product": "<String>",
      "model": "<String>",
      "board": "<String>"
    },
    "ro": {
      "crypto": {
        "state": "<boolean>" // ro.crypto.state
      },
      "product": {
        "firstAPILevel": "<int>" //ro.product.first_api_level
      }
    },
    "packageManager": {
      "featureVerifiedBoot": "<boolean>" // PackageManager.FEATURE_VERIFIED_BOOT
      "mainLinePatchLevel": "<String>"
    },
    "keyguardManager": {
      "isDeviceSecure": "<boolean>" // KeyguardManager.isDeviceSecure()
    },
    "biometricManager": {
      "deviceCredential": "<boolean>", // BiometricManager.canAuthenticate(BiometricManager.Authenticators.DEVICE_CREDENTIAL) or BiometricManager.canAuthenticate(Authenticators#DEVICE_CREDENTIAL)
      "biometricStrong": "<boolean>" // BiometricManager.canAuthenticate(Authenticators#BIOMETRIC_STRONG)
    },
    "devicePolicyManager": {
      "passwordComplexity": "<int>" //DevicePolicyManager.getPasswordComplexity(), PASSWORD_COMPLEXITY_NONE, PASSWORD_COMPLEXITY_LOW, PASSWORD_COMPLEXITY_MEDIUM, or PASSWORD_COMPLEXITY_HIGH
    }
  }
}  
 
// body (Apple)
{
  "iss": "<String>", // TrustSDK_<SDKVersion>
  "sub": "<String>", // Base64 encoded pubkey_mTLS_fingerprint (SHA256)>
  "iat": <NumericDate>,
  "type": "apple",
  "nonce": "<String>", // base64 encoded bytes
  "assertion": "<CBOR>", //CBOR assertionObject
  "deviceAttributes": { //see DSR-RFC-06
    "UIDevice": {
      "systemName": "<String>", // UIDevice.systemName
      "systemVersion": "<String>", // UIDevice.systemVersion
      "identifierForVendor": "<UUID>" // UIDevice.identifierForVendor
    }
    "appVersion" : "<String>",
  }
}  
 
// Signature
{..}

Device Token (device_token)

• sent from Device Management Service (GMS) to TrustClient to PEP (or directly from GMS to PEP)
• contains standard values from OAuth2.0 Certificate-Bound Access Tokens and
  • verdict_json ( Google Integrity API)
  • assertion (iOS)
  • device_attributes_security (see dsr-rfc-06)
  • UUID_device ↔ KVNR relation
• signed with privateKey_GMS
• see DSR-RFC-02 for corresponding sequence diagram

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123

// Header
{
 "typ": "JWT",
 "alg": "ES256", // NIST P-256,
 "x5c": [
    "<cert_GMS>",
    "<intermediate_1>",
    "<intermediate_n>"
  ] // see RFC-7515, 4.1.6>
}
 
// body (Android)  {
  "iss": "<String>", // GMS-ID or Domain
  "sub": "<String>", // pubkey_mTLS_fingerprint (SHA256)
  "iat": "<NumericDate>",
  "exp": "<int>", // expiration date
  "jti": "<UUID>", // random UUID - for blacklisting before expiration
  "type": "android",
  "userIdentifier": "<String>", // KVNR
  "deviceHealth": { //see DSR-RFC-06
    "integrityVerdict": {
      "appIntegrity": {
        "appRecognitionVerdict": "<String>", // PLAY_RECOGNIZED, UNRECOGNIZED_VERSION, UNEVALUATED
        "packageName": "<String>", // e.g. com.package.name
        "certificateSha256Digest": "<String>", // e.g. 6a6a1474b5cbbb2b1aa57e0bc3
        "versionCode": "<String>" // e.g. 42
      },
      "deviceIntegrity": {
        "deviceRecognitionVerdict": [
          "<String>",
          "<String>"
        ] //  MEETS_DEVICE_INTEGRITY, MEETS_BASIC_INTEGRITY, MEETS_STRONG_INTEGRITY, MEETS_VIRTUAL_INTEGRITY, empty string
      },
      "accountDetails": {
        "appLicensingVerdict": "<String>" // LICENSED, UNLICENSED, or UNEVALUATED
      }
    },
    "keyIdAttestation": {
      "attestationVersion": "<int>", // 1, 2, 3, 4, 100, 200
      "attestationSecurityLevel": "<int>", // Software  (0),TrustedEnvironment  (1), StrongBox  (2),
      "keyStore": {
        "type": "<String>", // KEY_MASTER, KEY_MINT
        "version": "<int>",
        "securityLevel": "<int>" // Software  (0),TrustedEnvironment  (1), StrongBox  (2),
      },
      // attestation challenge is not forwarded!
      "softwareEnforced": { // content is optional
        // see DSR-RFC-06
      },
      "teeEnforced": { // content is optional
        // see DSR-RFC-06
      }
    },
    "deviceAttributes": { //see DSR-RFC-06
      "build": {
        "version": {
          "sdkInit": "<int>", // Build.VERSION.SDK_INIT,
          "securityPatch": "<String>" // Build.VERSION.SECURITY_PATCH
        },
        "manufacturer": "<String>",
        "product": "<String>",
        "model": "<String>",
        "board": "<String>"
      },
      "ro": {
        "crypto": {
          "state": "<boolean>" // ro.crypto.state
        },
        "product": {
          "firstAPILevel": "<int>" //ro.product.first_api_level
        }
      },
      "packageManager": {
        "featureVerifiedBoot": "<boolean>" // PackageManager.FEATURE_VERIFIED_BOOT
      },
      "keyguardManager": {
        "isDeviceSecure": "<boolean / null>" // KeyguardManager.isDeviceSecure()
      },
      "biometricManager": {
        "deviceCredential": "<boolean / null>", // BiometricManager.canAuthenticate(BiometricManager.Authenticators.DEVICE_CREDENTIAL) or BiometricManager.canAuthenticate(Authenticators#DEVICE_CREDENTIAL)
        "biometricStrong": "<boolean / null>" // BiometricManager.canAuthenticate(Authenticators#BIOMETRIC_STRONG)
      },
      "devicePolicyManager": {
        "passwordComplexity": "<int>" //DevicePolicyManager.getPasswordComplexity(), PASSWORD_COMPLEXITY_NONE, PASSWORD_COMPLEXITY_LOW, PASSWORD_COMPLEXITY_MEDIUM, or PASSWORD_COMPLEXITY_HIGH
      }
    }
  },
  "cnf": { // confirmation claim, RFC-8705
    "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" //  X.509 Certificate SHA-256 Thumbprint
  }
}  
 
// body (Apple)  
{
  "iss": "<String>", // GMS-ID or Domain
  "sub": "<String>", // pubkey_mTLS_fingerprint (SHA256)
  "iat": "<NumericDate>",
  "exp": "<int>", // expiration date
  "jti": "<UUID>", // random UUID - for blacklisting before expiration
  "type": "apple",
  "userIdentifier": "<String>", // KVNR
  "deviceHealth": { // see DSR-RFC-06
    "assertion": {
      "rpID": "<int>", // A hash of your app’s App ID, which is the concatenation of your 10-digit team identifier, a period, and your app’s CFBundleIdentifier value.
      "counter": "<int>", // A value that reports the number of times your app has used the attested key to sign an assertion.
      "riskMetric": "<int>" //  indicates the number of attested keys associated with a given device over the lifetime of the device. Look for this value to be a low number.
    },
    "deviceAttributes": { //see DSR-RFC-06
      "UIDevice": {
        "systemName": "<String>", // UIDevice.systemName
        "systemVersion": "<String>", // UIDevice.systemVersion
        "identifierForVendor": "<UUID>" // UIDevice.identifierForVendor
      },
      "appVersion": "<String>"
    }
  },
  "cnf": { // confirmation claim, RFC-8705
    "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" // X.509 Certificate SHA-256 Thumbprint
  }
}  
 
// Signature
{..}

Trust Client Certificate Signing Request (CRL)

• sent from TrustClient to Device Management Service (GMS) and then to GMS CA for requesting / issuing Cert_mTLS
• contains standardized information
• signed by TrustClient with privKey_mTLS
• see DSR-RFC-01 for corresponding sequence diagram

1
2
3
4

// PKCS #10
Common Name = TRUST_CLIENT
Country Name = DE
Organization = DSR_POC

Trust Client Certificate (cert_mTLS)

• issued by Device Management Service (GMS) CA to TrustClient / device
• attests the device’s/app’s pubkey_mTLS (device identity)
• must contain KVNR
• see DSR-RFC-01 for corresponding sequence diagram

1

//tbd

Session Token (session_token_fd)

• sent from health service (FD) to TrustClient after successful device rating
• allows using session for a defined period of time without another device attestation
• signed by health service (FD)
• see DSR-RFC-02 for corresponding sequence diagram

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

// header
{
  "typ": "JWT",
  "alg": "ES256", // NIST P-256,
  "x5c": [
    "<cert_FD>",
    "<intermediate_1>",
    "<intermediate_n>"
  ], //see RFC-7515, 4.1.6> // OR
  "jwk": { // example!
    "kty": "EC",
    "crv": "P-256",
    "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
    "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
    "kid": "Public key used in JWS spec Appendix A.3 example"
  }
}
 
// body
{
  "iss": "https://server.example.com", //Fachdienst FQDN
  "sub": "brian@example.com", // Fachdienst internal user ID
  "iat": 1467324320, // issuance date
  "exp": 1467324920, // expiration date
  "jti": "<unique token ID>", // for blacklisting before expiration
  "cnf": { // confirmation claim, RFC-8705
    "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" //  X.509 Certificate SHA-256 Thumbprint
  }
}
 
// signature
{..}

2.5 - DSR-RFC-05 UI Flows

Introduction

To demonstrate the integration of DSR in mobile applications we provide the sample implementations of Frontend and Trust Client for Google Android and Apple iOS.

Android Registration and Data Access

2.6 - DSR-RFC-06 Device Security Attributes

Introduction

This RFC defines which Zero Trust signals are collected on- and off-device for security rating.

Minimal Trust Base for Registration

Minimal/basic trust that is needed for a successful registration at GMS and thus for participating in the DSR. Is verified by GMS during registration process.

Android

Google Play Integrity API

Descriptions are partially taken from the Android Developers Play Integrity doucmentation.

Android Key & ID Attestation

Descriptions are partially taken from the Android Developers Key & ID Attestation article.

iOS

App Attest Service

Descriptions are partially taken from the Apple Developer DeviceCheck documentation.

Device Rating Attributes

Device security attributes that need to be provided by a device when trying to access a resource. GMS verifies token authenticity / integrity as well as app/Trust SDK info and forwards all information in device_token to PEP.

Android

Google Play Integrity API

see Minimal Trust Base for Registration.

Android Key & ID Attestation

see Minimal Trust Base for Registration.

Additional Security Attributes

Descriptions are partially taken from the Android Enterprise Developers Zero Trust signals documentation.

iOS

App Attest Service

Descriptions are partially taken from the Apple Developer DeviceCheck documentation.

Additional Security Attributes

2.7 - DSR-RFC-09 Health Service API

Structure of the Health Service

A concrete instance of a FD service is identified via FQDN

The DSR “dummy” health service provides the following business APIs / resources

Scaling and load balancing is done in the background, invisible to the clients.

API Documentation

see poc-dsr-fd on GitHub.

Test Data ePrescription API

Test Data emergency data API

Input Data for Policy Decision Point

Input data for access decisions by the Policy Decision Point is independent of the DSR “dummy” health Service or its APIs and results from the external sources. The Policy Enforcement Point is responsible to determine appropriate input, verify and submit to the Policy Decision Point for decision according to a JSON schema:

Input Example for iOS Devices

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

{
  "request": {
    "method": "GET",
    "path": "/api/v1/notfalldaten",
    "clientIP": "XXX.XXX.XXX.XXX",
    "countryCode": "DE"
  },
  "deviceTokenValid": true,
  "deviceTokenPayload": {
    "type": "IOS",
    "userIdentifier": "X114428530",
    "deviceHealth": {
      "assertion": {integrityVerdict         "counter": 1,
        "rpID": "XXXXXX",
        "riskMetric": "unavailable"
      },
      "deviceAttributes": {
        "systemVersion": "16.6",
        "systemName": "iOS",
        "identifierForVendor": "XXXXXX",
        "systemModel": "iPhone13,3"
      }
    },
    "iss": "DSR GMS 1.0.0",
    "sub": "XXXX",
    "iat": 1234567890,
    "exp": 1234567890,
    "cnf": {
      "x5t#S256": "XXXXXX"
    },
    "jti": "XXXXXX"
  }
}

Input Example for Android Devices

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131

{
  "request": {
    "method": "GET",
    "path": "/api/v1/notfalldaten",
    "clientIP": "XXX.XXX.XXX.XXX",
    "countryCode": "DE"
  },
  "deviceTokenValid": true,
  "deviceTokenPayload": {
    "type": "ANDROID",
    "userIdentifier": "TEST KVNR",
    "deviceHealth": {
      "integrityVerdict": {
        "appIntegrity": {
          "appRecognitionVerdict": "UNRECOGNIZED_VERSION",
          "packageName": "de.gematik.dsr.android",
          "certificateSha256Digest": [
            "XXXXXX"
          ],
          "versionCode": 1
        },
        "deviceIntegrity": {
          "deviceRecognitionVerdict": [
            "MEETS_DEVICE_INTEGRITY"
          ]
        },
        "accountDetails": {
          "appLicensingVerdict": "UNLICENSED"
        }
      },
      "keyIdAttestation": {
        "attestationVersion": 200,
        "attestationSecurityLevel": 1,
        "softwareEnforced": {
          "creationDateTime": "2023-07-24T10:59:02.933Z",
          "usageExpireDateTime": "2024-07-23T12:59:02Z",
          "activeDateTime": "2023-07-24T09:59:02Z",
          "attestationApplicationId": {
            "packageInfos": [
              {
                "packageName": "de.gematik.dsr.android",
                "version": 1
              }
            ],
            "signatureDigests": [
              "XXXXXX"
            ]
          },
          "rootOfTrust": null,
          "originationExpireDateTime": "2024-07-23T12:59:02Z"
        },
        "teeEnforced": {
          "purpose": [
            2,
            3
          ],
          "attestationIdDevice": "XXXXXX",
          "keySize": 256,
          "osVersion": 130000,
          "origin": 0,
          "osPatchLevel": 202306,
          "attestationIdModel": "XXXXXX",
          "attestationIdProduct": "XXXXXX",
          "vendorPatchLevel": 20230605,
          "attestationApplicationId": null,
          "noAuthRequired": true,
          "rootOfTrust": {
            "verifiedBootKey": "XXXXXX",
            "deviceLocked": true,
            "verifiedBootState": "VERIFIED",
            "verifiedBootHash": "XXXXXX"
          },
          "algorithm": 3,
          "digest": [
            4
          ],
          "ecCurve": 1,
          "attestationIdManufacturer": "XXXXXX",
          "attestationIdBrand": "XXXXXX",
          "bootPatchLevel": 20230605
        },
        "keyStore": {
          "type": "KEY_MINT",
          "version": 200,
          "securityLevel": 1
        }
      },
      "deviceAttributes": {
        "build": {
          "version": {
            "sdkInit": 33,
            "securityPatch": "2023-06-05"
          },
          "manufacturer": "Google",
          "product": "oriole",
          "model": "Pixel 6",
          "board": "oriole"
        },
        "ro": {
          "crypto": {
            "state": true
          },
          "product": {
            "firstAPILevel": 31
          }
        },
        "packageManager": {
          "featureVerifiedBoot": true
        },
        "keyguardManager": {
          "isDeviceSecure": true
        },
        "biometricManager": {
          "deviceCredential": true,
          "biometricStrong": true
        },
        "devicePolicyManager": {
          "passwordComplexity": 327680
        }
      }
    },
    "iss": "DSR GMS 1.0.0",
    "sub": "XXXXXX",
    "iat": 1234567890,
    "exp": 1234567890,
    "cnf": {
      "x5t#S256": "XXXXXX"
    },
    "jti": "XXXXXX"
  }
}

The structural check of the device token (signature, validity, mTLS fingerprint matching) is performed in the Policy Enforcement Point before the Policy Decision Point is called. The result of this check is passed to the Policy Decision Point with the deviceTokenValid attribute.

Access Decision / Verdict by the PDP

For example, the positive decision look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "allow": true,
  "device": {
    "allow": true,
    "violations": []
  },
  "security": {
    "allow": true,
    "violations": []
  }
}

A negative decision provides hints about which checks failed and looks like the following examples:

Failed Android Device

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

{
  "allow": false,
  "device": {
    "allow": false,
    "violations": [
      {
        "error": "device_android_api_level_violation",
        "error_description": "Device is required to have API level 33 or higher. Current API level: 11."
      },
      {
        "error": "device_android_encryption_disabled",
        "error_description": "Device is required to have encryption enabled."
      },
      {
        "error": "device_android_patch_level_violation",
        "error_description": "Device is required to have patchlevel 2022-12-01 or higher. Current patch level: 2019-01-01."
      },
      {
        "error": "device_unknwown_app",
        "error_description": "App is not approved by gematik."
      }
    ]
  },
  "security": {
    "allow": true,
    "violations": []
  }
}

Failed iOS Device

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

{
  "allow": false,
  "device": {
    "allow": false,
    "violations": [
      {
        "error": "device_ios_invalid_version",
        "error_description": "Device is required to have iOS 14.0.0 or higher. Current version: 13.0.0."
      },
      {
        "error": "device_unknown_app",
        "error_description": "App is not approved by gematik."
      }
    ]
  },
  "security": {
    "allow": true,
    "violations": []
  }
}

2.8 - DSR-RFC-11 Mobile Vulnerability Management

Introduction

tbd

Example Vulnerabilities

Mali GPU Kernel Driver may elevate CPU RO pages to writable

Samsung TrustZone Keymaster

Internet to Baseband Remote Code Execution Vulnerabilities in Exynos Modems

Smartphone Fingerprint Authentication Brute-force Attack

Implementation

The implementation of the pipeline was carried out using the following resources:

• cpe-guesser
• CVE search library

The main.py file receives a list of “keywords” such as “python3 main.py samsung galaxy s6”. These keywords are searched for in a local redis-server instance, which contains all CPEs from NIST.

The found CPEs are formatted properly and queried with the nvdlib at the NIST CVE API. The found CVEs are processed and outputted.

Challenges

• The used API has a limited number of requests.
• Not all devices have “proper” CPEs.
• It is difficult to automatically determine if the found CVEs are fixed in the next patch.

3 - Limitations

Introduction

The goal of the Device Security Rating Proof of Concept is to demonstrate and discuss the feasibility of the central Zero Trust building blogs for the telematics infrastructure. For this reason, not all services and functionality shown in the Zero Trust architecture overview below and described in the Zero Trust concept paper are present in the PoC concept and source code. It is possible that the integration of the missing components and functionality will be investigated in a future release.

In the following sections, the current limitations of the DSR PoC will be described in detail.

General

Production Readiness

Since this software is not a productive version, please submit an issue or pull request for any bugs or vulnerabilities you find. In case of a responsible disclosure, please follow instructions on https://www.gematik.de/datensicherheit#c1227.

Cloud Native Architecture

For our PoC, we initially focused on a bare metal runtime using Docker and Docker Compose. The Docker images are built using cloud-friendly frameworks like Quarkus and Go Gin. However, they were specifically not designed to be run as pods in a Kubernetes cluster.

Currently, we offer Nginx as the sole API gateway and TLS termination solution. Consequently, our Policy Enforcement Point (PEP) only supports this particular deployment. In production-ready cloud setups, greater flexibility is required to support Kubernetes Ingress or other cloud-native API publishing offerings.

Lastly, the configuration and secrets management should be optimized, particularly in terms of key management. This involves integration with a Key Management Service (KMS) provided by the cloud provider, ensuring more secure and efficient handling of sensitive data.

Minimal Requirements for Trust Client Hardware

The PoC uses the latest available device attestation mechanisms. This means that an Android device with at least Android 12 (API level 31)* or an iOS device with at least iOS 14.0 is required to test the Tust Client functionality. We are aware that this excludes a large number of devices currently on the market. Possible mitigation strategies are under discussion and will be made available at a later date.

*The device must be initially released by an OEM with that version of Android. Upgraded devices do not always provide the required functionality.

Functionality

Trust Client for Windows / Linux / Android Derivates

The PoC is focused on mobile applications and devices. We are already evaluating attestation mechanisms provided by TPMs for desktop operating systems such as Windows and Linux. Attestation mechanisms for Android derivatives such as Huawei Harmony OS or Graphene OS will also be considered at a later stage.

IdP Federation Integration

The user identification & authentication part of resource access provided by the IdP Federation is currently outside the scope of the PoC. As the user and device/application authentication flows are currently independent and will only be merged at the PEP, integration will be provided at a later stage.

Monitoring, Reporting & Telemetry

Our current logging setup relies on the basic logging features provided by the web frameworks we use. We haven’t yet fine-tuned this logging to capture all the detailed information needed for running such critical system.

At our Policy Enforcement Point (PEP), we use the standard logging provided by the Open Policy Agent for tracking both real and test policy enforcement. But, when we move to a production environment, we need to be more careful about our logging. We have to decide what information should be logged, especially making sure we don’t log any private data. It’s important to keep our data safe and private.

Also, we need to add more tools to our software to better check the system’s health. This means putting telemetry - a way to measure system performance - in key parts of our system. This will help us keep a close eye on how each part is doing and maintain the system better.

Mobile Vulnerability Management

Although the PoC includes initial work on vulnerability management for mobile devices, further research is needed.

Device Management Service (GMS) Certificate Authority

The PoC currently uses a rudimentary CA implementation for demonstration purposes only. In a future release, this part will be enhanced with a proper framework and protocols. We are already investigating client certificate issuance based on Automated Certificate Management Environment (ACME) Device Attestation.

Authentication with the Electronic Health Card

The current implementation of device/application registration uses a virtual electronic health card and cannot yet be used with a physical electronic health card.

Services & Infrastructure

PIP & PAP

In the PoC, PIP and PAP are not yet implemented as a standalone service. This issue will be addressed at a later stage.

User Portal

The Zero Trust concept paper describes a user portal that allows users to manage their devices and set individual settings for their interaction with the TI Zero Trust infrastructure. In the PoC, this functionality was integrated into the dummy health client for simplicity.

Security & Privacy

Since this software is not a productive version, please submit an issue or pull request for any bugs or vulnerabilities you find. In case of a responsible disclosure, please follow instructions on https://www.gematik.de/datensicherheit#c1227.

Device Management Service (GMS) Trusted Execution Environment

The Device Management Service (GMS) currently runs without enhanced isolation or sandboxing. This issue will be addressed at a later date.

Privacy-Enhancing Measurements

Although privacy has been one of the key design principles for the PoC, the current architecture does not incorporate advanced privacy-enhancing mechanisms. This issue will be addressed at a later stage.

4 -

Welcome to the gematik contributing guide

Thank you for investing your time in contributing to our projects!

In this guide you will get an overview how you can contribute to our projects by opening an issue, creating, reviewing and merging a pull request.

Getting started

Issues

Create a new issue

If you spot a problem with the docs, search if an issue already exists. If a related issue doesn’t exist, you can open a new issue.

Solve an issue

Scan through our existing issues to find one that interests you. If you find an issue to work on, you are welcome to open a PR with a fix.

Coding Style

gematik projects follow the google style guide conventions. Please follow them when working on your contributions.

Commit your update

Commit the changes once you are happy with them.

Pull Request Process

• When you’re finished with the changes, create a pull request, also known as a PR.
• Fill the pull request template so that we can review your PR. This template helps reviewers to understand your changes as well as the purpose of your pull request.
• Don’t forget to link the PR to the issue if you are solving one.
• Once you submit your PR, a project team member will review your proposal. We may ask questions or request additional information.
• We may ask for changes to be made before a PR can be merged, either using suggested changes or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
• As you update your PR and apply changes, mark each conversation as resolved.
• You may merge the Pull Request in once you have the sign-off of two other developers, or if you do not have permission to do that, you may request the second reviewer to merge it for you.

Your PR is merged!

Once your PR is merged, your contributions will be publicly visible on the gematik github page.