Concepts

• 1: Device Management Service (GMS)
• 2: Policy Enforcement Point & Policy Decision Point
• 3: Policy Information Point & Policy Administration Point
• 4: Trust Client

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

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.

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.

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).