(discussion) strongbox key storage limitations

[gmulhearn]

I see strongbox is being utilised for Android, which is great. Was wondering if there is any concerns or insights the devs could share about usage of the strongbox enclave in practice, e.g. in practice is there some maximum number of keys that can be created on strongbox?

I can’t seem to find straight answers for that question, likely Bcus it’s HSM chip/manufacturer dependent. chatgpt seems to think it’s in the 50-100 range… but surely that won’t go far when considering EUDI use cases of batch issuance of high assurance creds.. is there something I’m missing about how ARF expects this usage to be achieved (given they call out Strongbox as a WSCD)?

Thanks in advance for your input!

@TimoGlastra @berendsliedrecht

(P.S. i also posted in credo discord, but i think it's been lost: https://discord.com/channels/1022962884864643214/1179453305856991263/1326145311961382984)

[berendsliedrecht]

Hi! We have not encountered any issues with regards to the amount of keys created. Now, even if this limitation is not there (which it might be, but we have not encountered it, yet), we will still have an issue with authenticating to the secure enclave for batch issuance. With batch issuance, we need to create N keys for N credentials, which will also in turn have us prompt the user N times to authenticate with biometrics, a terrible UX.

There are some experiments going on which would allow us to create a single hardware-backed key pair and, provable, derive new keys from that. I am not a 100% sure that is will be LoA high, but we cannot prompt the user multiple times for every credential in the batch.

Hopes this helps a bit!

[gmulhearn]

@berendsliedrecht thnx for the info, useful to know. I haven't ran into #keys limitation issues either yet fwiw.

Those experiments sound interesting, do you have any pointers to where that is happening? no worries if not. Sounds like what the ARF is alluding to in it's high level requirements, but unfortunately the ARF doesn't really explain how:

The WTE contains a public key. By including this public key in the WTE, the Wallet Provider attests that the corresponding private key is protected by a certified WSCA/WSCD that has the properties and security posture described in the WTE. The PID Provider or Attestation Provider then asks that WSCA to create a key pair for its new PID or attestation, and to prove that this new key is associated with the key in the WTE. Association primarily means that the PID or attestation private key is protected by the same WSCA as the WTE private key. A full description of the concept of key association is given in the forthcoming White Paper on Wallet Trust Evidence. Therefore, the PID Provider or Attestation Provider can be sure that the security level of the new PID or attestation key is the same as the security level of the WTE key. At the moment of writing this version of the ARF, it is not fully clear how many WSCDs will support the cryptographic functionalities necessary to generate a proof of association. Therefore, the creation of a proof of association in a WSCA is recommended (SHOULD), not required (SHALL). In this way, once a Wallet Instance has access to a WSCD/WSCA that supports the required cryptographic functionalities, proofs of association can be used as described in this Topic.

[berendsliedrecht]

I believe the following issue+pr is relevant, but it has been a bit since I last looked at them. The ARF currently, indeed, does not explain how sadly. I assume it will take some time before the ARF mentions this. It is quite a new feature. Also, I am not sure whether this will be the end solution, it might be a solution, but not the definitive one.

• Support for Hierarchical Deterministic Keys (HDK) openid/OpenID4VCI#359
• add key attestations openid/OpenID4VCI#389

[sander]

Hi, I got notified about this thread because of the mention of the OpenID4VCI issue I opened. Good to see more open source implementations of secure area interfacing. My notes about this topic might be of interest to you as well: Wallet Secure Cryptographic Commons.

@berendsliedrecht:

There are some experiments going on which would allow us to create a single hardware-backed key pair and, provable, derive new keys from that. I am not a 100% sure that is will be LoA high, but we cannot prompt the user multiple times for every credential in the batch.

We have designed HDK to achieve LoA High. See ETSI TR 119 476 v1.2.1 § 4.4.4.2 for details.

I believe the following issue+pr is relevant, but it has been a bit since I last looked at them. The ARF currently, indeed, does not explain how sadly. I assume it will take some time before the ARF mentions this. It is quite a new feature. Also, I am not sure whether this will be the end solution, it might be a solution, but not the definitive one.

See Topic B for the planned ARF update.

Once ZKP from Topic G is sufficiently developed for all relevant use cases, interop on HDK may not be needed anymore.