Difference between revisions of "Smartphone Identity"
(→Problems) |
(→=Privacy Challenge) |
||
| (13 intermediate revisions by the same user not shown) | |||
| Line 7: | Line 7: | ||
The goal of essential all [[Authentication]] of [[Identity]] is the [[Authorization]] of access to some resource that is important to the holder of the [[Credential]]. In the real-world a credential will have some means for identification of the user together with some attributes that are possessed by the user, such as the authority to driver a car or access state benefits. | The goal of essential all [[Authentication]] of [[Identity]] is the [[Authorization]] of access to some resource that is important to the holder of the [[Credential]]. In the real-world a credential will have some means for identification of the user together with some attributes that are possessed by the user, such as the authority to driver a car or access state benefits. | ||
| + | While some folks say that their can be no digital identity, only digital identifiers, the range of credentials that can be stored on the phone will grow to the point where a large part of your identity is on your phone. | ||
| + | |||
| + | |||
| + | ==Problems== | ||
| + | * The "Evil Maid Attack" is a house helper getting access to a computing device and cloning it. Mitigations do exist for this attack. | ||
| + | * Any co-resident app on the device might be able to connect to the local access point to acquire access to the user credentials as a trusted app (as it is in "localhost" origin.) | ||
===Inclusion=== | ===Inclusion=== | ||
* There is always a tension between using the latest new security feature and providing support for the widest range of customers possible. | * There is always a tension between using the latest new security feature and providing support for the widest range of customers possible. | ||
| − | * A similar tension exists between the | + | * A similar tension exists between the commercial push to sell a new product versus support for legacy systems. |
| − | * | + | * Successful ecosystems try for a balance between support strategies for the existing communities with encouraging growth that will improve the overall health of the ecosystem as it moves into an uncertain future. |
* With those tensions in mind here are some support strategies for the greatest spread of the benefit of technology for all: | * With those tensions in mind here are some support strategies for the greatest spread of the benefit of technology for all: | ||
# Accessibility - support for the widest possible range of human abilities. | # Accessibility - support for the widest possible range of human abilities. | ||
| Line 16: | Line 22: | ||
# Backwards compatibility - consistent with timely responses to new attack vectors - allow users to stay with their existing devices for both cost and sustainability reasons. | # Backwards compatibility - consistent with timely responses to new attack vectors - allow users to stay with their existing devices for both cost and sustainability reasons. | ||
| − | == | + | ===Privacy Challenge=== |
| − | * The | + | * The obvious leakage is from the Issuing and Verification Providers. |
| − | * | + | * Less obvious leakage if from attacks on user data directly to the Smartphone or to the communications channel. |
==Creation== | ==Creation== | ||
| − | The issuer of the user credential will need to have the trust of both the holder and the verifier of the credential, each with very different requirements as addressed below. | + | The issuer of the user credential will need to have the trust of both the holder and the verifier of the credential, each with very different requirements as addressed below. In cases like the [[Mobile Driver's License]] the issuer will assure that an appropriate application is installed on the phone (see verification) before providing a credential from the user. Secure credentials will never be passed outside of the holder's control without explicate release of only those data elements that are required by the verifier after consent is received from the user. |
==Storage== | ==Storage== | ||
| Line 27: | Line 33: | ||
"The goal is simple: Make it as hard as possible for attackers to steal credentials and use them at their leisure. Let's even make it difficult for users to clone their own credentials to share with other users. In addition to this protection, let's ensure that adding extra factors such as biometric authentication provides a strong assurance of who the user is." | "The goal is simple: Make it as hard as possible for attackers to steal credentials and use them at their leisure. Let's even make it difficult for users to clone their own credentials to share with other users. In addition to this protection, let's ensure that adding extra factors such as biometric authentication provides a strong assurance of who the user is." | ||
| − | . | + | |
| + | All modern smart phones include a [[Trusted Execution Environment]] that is either a separate TPM V1 chip or a software TPM V2 app running in the TEE that is part of the ARM hardware architecture. These TPMs will typically support signing and decryption operations within the TEE for the common FIPS approved algorithms of RSA and EC. That means that other encryption schemes, such as that used for [[Bitcoin]] can be stored hidden inside the TEE, but must be exported into the main process to run cryptographic processes. It is highly likely in 2021 that NIST will soon at the the FIPS approved algorithms to protect against [[Quantum Computing Threat]]s to existing cryptography. Then it will be several years before those become commonly used in commerce. | ||
==Verification== | ==Verification== | ||
| − | The [[Relying Party]] adoption will determine the adoption of the technology. The reader of the data in the [[Smartphone]] may involve another human or be fully automated depending on the type of [[Authorization]] that the user is seeking. | + | The [[Relying Party]] adoption will determine the adoption of the technology. The reader of the data in the [[Smartphone]] may involve another human or be fully automated depending on the type of [[Authorization]] that the user is seeking. "Establishing trust requires a bit of proof that the phone was manufactured to the expected security standard. User Identity is contained in the secret keys and credentials stored on the phone after signing by the issuers. The verifier will need some means to verify those cryptographic signatures. |
| + | |||
| + | Attestation of the application running on the phone is challenging, but the technology does exist. It is expect that all applications on the phone will be able to identify themselves with some software statement created by the designers and perhaps some additional proof that the code has not been altered since it was installed on the phone. That last bit of proof will only be provided for high assurance use cases as it is expensive to deploy and maintain. | ||
| + | |||
| + | The biometric proofs that are created in the phone can be signed by the phone and sent to the verifier which requires one of the levels of proof of both the application that is running on the phone as well as the configuration of the phone. One example of configuration information is whether the user has enabled a lock screen to prevent others from using the phone. Liveness tests that prove the continued presence of the user during the session can also be provided by the application. There is some limitation on the ability of applications running on the iPhone to provide the same level of trust for applications and configuration as are available from Android in 2021. | ||
==References== | ==References== | ||
Latest revision as of 17:25, 18 November 2021
Contents
Full Title
What is the best way to construct systems that give users the ability to carry Identity information in their mobile Digital communications devices?
Context
"Around the world cellular connectivity is more ubiquitous than clean running water. " is how Phil Vachon starts his discussion of "The Identity in Everyone's Pocket" an article in the Communications of the ACM.[1] This requires development of technology solutions for the creation, storage and verification of digital credentials in a manner that respects the user's needs and desires. This page is a summary of that article as it impacts developers of applications running in those three environments.
The goal of essential all Authentication of Identity is the Authorization of access to some resource that is important to the holder of the Credential. In the real-world a credential will have some means for identification of the user together with some attributes that are possessed by the user, such as the authority to driver a car or access state benefits.
While some folks say that their can be no digital identity, only digital identifiers, the range of credentials that can be stored on the phone will grow to the point where a large part of your identity is on your phone.
Problems
- The "Evil Maid Attack" is a house helper getting access to a computing device and cloning it. Mitigations do exist for this attack.
- Any co-resident app on the device might be able to connect to the local access point to acquire access to the user credentials as a trusted app (as it is in "localhost" origin.)
Inclusion
- There is always a tension between using the latest new security feature and providing support for the widest range of customers possible.
- A similar tension exists between the commercial push to sell a new product versus support for legacy systems.
- Successful ecosystems try for a balance between support strategies for the existing communities with encouraging growth that will improve the overall health of the ecosystem as it moves into an uncertain future.
- With those tensions in mind here are some support strategies for the greatest spread of the benefit of technology for all:
- Accessibility - support for the widest possible range of human abilities.
- Some low cost solutions - support for all income groups and countries.
- Backwards compatibility - consistent with timely responses to new attack vectors - allow users to stay with their existing devices for both cost and sustainability reasons.
Privacy Challenge
- The obvious leakage is from the Issuing and Verification Providers.
- Less obvious leakage if from attacks on user data directly to the Smartphone or to the communications channel.
Creation
The issuer of the user credential will need to have the trust of both the holder and the verifier of the credential, each with very different requirements as addressed below. In cases like the Mobile Driver's License the issuer will assure that an appropriate application is installed on the phone (see verification) before providing a credential from the user. Secure credentials will never be passed outside of the holder's control without explicate release of only those data elements that are required by the verifier after consent is received from the user.
Storage
The User Experience on their Smartphone of acquiring, retentions and release of the information from the credentials on their smart phone will determine the rate of adoption of any new technology. The Technology of the smartphone and its operating system will determine the limits on both the user experience and the security of the storage of the credential. While each type of smartphone will have its own working set of technologies, the three actors will all need to agree that those technologies will be appropriate to the levels of privacy, security and user experience. Likewise the application that uses those technologies will need to use them in manner that will provide real levels of security, privacy and user experience..
"The goal is simple: Make it as hard as possible for attackers to steal credentials and use them at their leisure. Let's even make it difficult for users to clone their own credentials to share with other users. In addition to this protection, let's ensure that adding extra factors such as biometric authentication provides a strong assurance of who the user is."
All modern smart phones include a Trusted Execution Environment that is either a separate TPM V1 chip or a software TPM V2 app running in the TEE that is part of the ARM hardware architecture. These TPMs will typically support signing and decryption operations within the TEE for the common FIPS approved algorithms of RSA and EC. That means that other encryption schemes, such as that used for Bitcoin can be stored hidden inside the TEE, but must be exported into the main process to run cryptographic processes. It is highly likely in 2021 that NIST will soon at the the FIPS approved algorithms to protect against Quantum Computing Threats to existing cryptography. Then it will be several years before those become commonly used in commerce.
Verification
The Relying Party adoption will determine the adoption of the technology. The reader of the data in the Smartphone may involve another human or be fully automated depending on the type of Authorization that the user is seeking. "Establishing trust requires a bit of proof that the phone was manufactured to the expected security standard. User Identity is contained in the secret keys and credentials stored on the phone after signing by the issuers. The verifier will need some means to verify those cryptographic signatures.
Attestation of the application running on the phone is challenging, but the technology does exist. It is expect that all applications on the phone will be able to identify themselves with some software statement created by the designers and perhaps some additional proof that the code has not been altered since it was installed on the phone. That last bit of proof will only be provided for high assurance use cases as it is expensive to deploy and maintain.
The biometric proofs that are created in the phone can be signed by the phone and sent to the verifier which requires one of the levels of proof of both the application that is running on the phone as well as the configuration of the phone. One example of configuration information is whether the user has enabled a lock screen to prevent others from using the phone. Liveness tests that prove the continued presence of the user during the session can also be provided by the application. There is some limitation on the ability of applications running on the iPhone to provide the same level of trust for applications and configuration as are available from Android in 2021.
References
- ↑ Phil Vachon, The Identity in Everyone's Pocket CACM 64 No. 1 (2021-01)
