Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

DIS detailed with more information #285

Merged
merged 5 commits into from
Jun 17, 2024
Merged

DIS detailed with more information #285

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
91cf3c3
DIS detailed with more information
cmarco0 May 21, 2024
0a00ffb
Update DIS in smartphones
cmarco0 May 29, 2024
f3eb0a7
Editorial update italic format
cmarco0 May 29, 2024
6963b4e
Editorial update on spaces
cmarco0 May 29, 2024
31615cb
Apply suggestions from code review
peppelinux Jun 17, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions docs/en/wallet-attestation.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -103,8 +103,13 @@ Wallet Instance Initialization and Registration

**Device Integrity Service:** In this section the Device Integrity Service is considered as it is provided by device manufacturers. This service allows the verification of a key being securely stored within the device's hardware through a signed object. Additionally, it offers the verifiable proof that a specific Wallet Instance is authentic, unaltered, and in its original state using a specialized signed document made for this scope.

The service also incorporates details in the signed object, such as the device type, model, app version, operating system version, bootloader status, and other relevant information to assess the device has not been compromised. For Android the service used is `Key Attestation`_ in addition to `Play Integrity API`_, while for iOS the `DeviceCheck`_ service.
This service, specifically developed by the manufacturer, is already integrated within the Android or iOS SDKs, so there is no need for a predefined endpoint to access it. Moreover, as it is specifically developed in the mobile architecture, it does not need to be registered as a Federation Entity, through the national accreditation systems.
The service also incorporates details in the signed object, such as the device type, model, app version, operating system version, bootloader status, and other relevant information to assess the device has not been compromised. For Android the DIS is represented by **StrongBox Keymaster** which is a physical HSM installed directly on the motherboard, it has various feature, the one we are interested to is named `Key Attestation`_, developer can leverage its functionality by the usage of `Play Integrity API`_. *Key attestation* aims to provide a way to strongly determine if a key pair is hardware-backed, what the properties of the key are, and what constraints are applied to its usage.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more. 

For Android the DIS is represented by **StrongBox Keymaster** which is a physical HSM installed directly on the motherboard, it has various feature, the one we are interested to is named `Key Attestation`_,

This is wrong. Key Attestation is not part of StrongBox Keymaster and can also be used with a Trusted Execution Environment (TEE). The combined use of Key Attestation and Play Integrity Check allows you to create a DIS on Android which therefore guarantees both that the backend hardware key and the app are genuine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reading again the docs https://developer.android.com/privacy-and-security/keystore , key attestation is not part but it is only a supported feature by Stronghox Keymaster.

For Apple devices the DIS is represented by **Secure Enclave**, a dedicated secure subsystem integrated into Apple's SoCs. Apple iOS is more fragmented than Android, in this case exists a series of services named `DeviceCheck`_ which provide a framework and server interface to manage device-specific data securely, developer can leverage its functionality by the usage of the framework itself. *DeviceCheck* It can be used to attest to the integrity of the device, apps, and/or encryption keys generated on the device, ensuring they were created in a secure environment like Secure Enclave.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For Apple devices the DIS is represented only by DeviceCheck. Secure Enclave is just a system for storing keys securely on par with Strongbox or TEE. Furthermore, I don't agree with saying that Apple is more fragmented.


This services, specifically developed by the manufacturer, are already integrated within the Android or iOS SDKs, so there is no need for a predefined endpoint to access it. Moreover, as it is specifically developed in the mobile architecture, it does not need to be registered as a Federation Entity, through the national accreditation systems.
peppelinux marked this conversation as resolved.
Show resolved Hide resolved

For Apple devices Secure Enclave is available since the iPhone 5s (2013).
Strongbox Keymaster is different in that, because each smartphone manufacturer must decide whether to include it or not.

**Step 8**: The Device Integrity Service performs the following actions:

Expand Down
Loading