DIS detailed with more information #285
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
peppelinux
requested review from
grausof,
peppelinux,
fmarino-ipzs and
fventola-ipzs
grausof
reviewed
May 28, 2024
docs/en/wallet-attestation.rst
Outdated
| @@ -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. | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
grausof
reviewed
May 28, 2024
docs/en/wallet-attestation.rst
Outdated
| 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. | ||
| 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. |
There was a problem hiding this comment.
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.
|
As discussed during the editor's call we agreed that this PR must be changed according to the revision made, aiming to hold only the additional clarifications that would aim to improve the specification @cmarco0 ^ |
fventola-ipzs
approved these changes
May 29, 2024
Some words were written in a wrong italic format.
There was an error on some spaces.
grausof
approved these changes
Jun 17, 2024
peppelinux
reviewed
Jun 17, 2024
peppelinux
reviewed
Jun 17, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims to solve the issue #284
Added more information about the DIS (Device Integrity Service):
-What is for Android and iOS.
-Specified key attestation functionality for Android and iOS
-availability on smartphones