Privacy has not started to be taken into account in the ARF 1.4

[GSMA-EIG]

Privacy has not started to be taken into account in the ARF 1.4. The minimum would be to include the two following properties as mandatory objectives of the architecture:

1. Full unlinkability
2. Everlasting privacy (also known as « unconditional privacy » in the academic literature)

A basic definition of unlinkability would be to avoid tracking through metadata and other information not willingly revealed in clear by the user, even across subsequent transactions.
Everlasting privacy states that whatever happens after a transaction has taken place, no one will be able to mathematically retrieve any information about the hidden (meta)data that were used in the transaction, including if the private key that was used for the transaction is revealed,if an adversary has an unlimited amount of computing power or if they can use a quantum computer. This property ensures that users feel safe performing transactions knowing that their privacy will be preserved in the long term.
These objectives do not imply that users would be anonymous in all transactions, but ensure that the framework enables appropriate privacy depending on service needs.

Unlinkabilityshall be ensured:
• Not only across verifiers but also between any number of actors (including verifiers and issuers) and over time
• In all processes, including in the revocation process, i.e. whenever the user must prove that their assets ((Q)EAA, wallet, etc…) have not been revoked
From an architecture point of view, the underlying infrastructure shall not add any linkability to what the service has decided to share, especially since the user has no knowledge or understanding of the tracking information that might be spread by the underlying infrastructure and affect their privacy(especially when combined with “selective disclosure”).
This involves identifying efficient and generic ways of randomizing all the (meta)data that service purposes do not explicitly require in clear . For example, this means that;
• The signature provided by the issuer to the holder shall not be provided identically to the verifier but shall be “randomized”
• Same for the public key embedded in the signed (Q)EAA
• Metadata like the expiration date shall be hidden when shared with the verifier
• To verify the validity of a verifiable proof, the verifier shall not have to request a non-randomized identifier from the holder, which would create linkability

In addition, a full implementation of privacy by design for eIDAS should include:
• Blind signatures capabilities for the issuers
• The capability to generate minimized proofs (e.g. “I am over 18” instead of “here is my date of birth. Look at it and you’ll see I’m over 18”) and more generally work on predicates where the user shall just answer Yes or No
• The capability to authenticate user with self-generated pseudonyms
• These should be accompanied by all necessary proofs including the fact that the pseudonym is generated as it should and linked to the legitimate user

The framework could also include plausible deniability (i.e. the user being able to credibly claim that they did not perform a transaction which they actually did, without anyone being able to claim the contrary). However, plausible deniability is not compatible with audit requirements and therefore each service shall define whether / which transactions are eligible to plausible deniability.

Furthermore, all of this should be done without impacting security, and in particular, the following shall hold true:
• It shall not be technically possible for the WSCD to generate proofs independently without the user being involved
• (Q)EAA shall be holder bound in a process leveraging a SOG-IS listed protocols running on a WSCD
• Formal proofs of security and privacy shall be provided for the used protocols

The solution shall be available to as many people as possible immediately at launch.

On a common hardware, the calculations necessary for the transaction shall not take more than 100ms, so that, considering other latency factors e.g. checking the non-revocation of VCs, the full process would take less than 500ms.

For a future-proof framework he used protocols shall be PQC resistant, but without impacting any of the other properties.

In conclusion, there is no “light touch” way to solvethe privacy challenges of the current ARF:
• The privacy strategy/objectives shall be defined in a specific chapter, and shall at least include full unlinkability and everlasting privacy
• The protocols shall be amended: in their current form mDL and SD-JWT can not structurally support unlinkability, nor everlasting privacy. We recommend relying on anonymous credentials protocols, particularly of the BBS family which are the most efficient.

We have raised similar concerns previously (here) and are aware that such concerns echo those raised in an open letter published by renowned academics on 23/11/2023, which stated:
“Finally, the mobile wallet part of the regulation mentions in multiple places the need for the European Digital Identity Wallet to protect privacy, including data minimization, and prevention of profiling. However, our concerns remain that the draft regulation still enables large-scale tracking of citizens based on government-issued identifiers. Our concern that unobservability (towards the Wallet provider) and unlinkability are not sufficiently assured has not been addressed: this means the technical implementation will decide on core privacy safeguards and that relying parties will choose the Member State with the weakest protection. The current reference architecture does not use the state-of-the-art technologies such as anonymous credentials that have been developed more than 20 years ago. It is clear that, once mobile wallets are rolled out on a large scale, it will become exceedingly difficult to make further changes.”
Such concerns remain valid with the current version of the ARF.

[OBIvision]

Agree. The present ARF version is literally Surveillance by Design

A number of different means and approaches could be applied, but none are.
In addition to better ZK-proofs, we need to incorporate support for

• Trustworthy PKI (including non-linkable PKI) to address the many PKI installations
• Trustworthy QSCD (roaming authenticator) to delink dependency on BigTech controlled TEE

[ad-Orange]

One more thing...
BBS_Sharp_Short_TR.pdf

[OBIvision]

One more thing... BBS_Sharp_Short_TR.pdf

Indeed. Great work on aligning this with the standardization and ARF. Someone read http://www.credentica.com/the_mit_pressbook.html and the subsequent work ;-)

Several aspect still missing, but clearly on the right track and way better than the present non-compliant ARF surveillance model.

[OBIvision]

One more thing... BBS_Sharp_Short_TR.pdf

Who is @ad-Orange ? A one-time-only identity created just to disclose this raise questions. Contact me P2P.

[ad-Orange]

@OBIvision don't worry I'm not Satoshi Nakamoto . Some references:
Orange
We co-authored the pairing-free version of BBS+ (also called MAC_BBS), see the reference [BBDT16] in our BBS# paper or in the IETF Draft on BBS. BBS# is based on MAC_BBS not on U-Prove

GSMA
As you know, the GSMA has published different papers already referenced. In this thread, this one on privacy seems appropriate to recall.

Finally, I think the important part of your message is the "aspects still missing". Would you care to elaborate so that we can improve the proposal ? Thanks a lot in advance.

[sander]

Thank you @ad-Orange for publishing this work on BBS#. It is very interesting. I have questions however about the applicability to the EU Digital Identity in the short term.

Do you envision BBS# being applied for QEAA and Pub-EAA as well? If so, note that (EU) 2024/1183 requires these products to be signed or sealed by the issuer using a QSCD as per Annex V, point (g) and Annex VII, point (g). Typically QSCDs are qualified after certification for EN 419221-5:2018, and the designated bodies typically refer to the SOG-IS Agreed Cryptographic Mechanisms. I’m not aware of certified QSCDs that support creating BBS digital signatures, which BBS# requires for the issuer. Also, I’m not aware of an initiative at SOG-IS to agree on BBS. Next to that, we need to agree on Qualified Certificate and Advanced Electronic Signature profiles that support BBS. The overall process may take many years.

Given this duration, we may need to start today, but will not be able meet the European Digital Identity implementation deadlines for public body attestations. What do you think about having a transitional solution in the meantime? If this would be used, what would you see as requirements for such a solution, to ensure we make the transition to BBS in time?

I see most member states looking to apply the same cryptographic algorithms to PID as to QEAA and Pub-EAA. Typically public bodies would look for EN 419221-5:2018 certification when tendering their HSMs as well. Do you envision alternative devices being used to protect PID authenticity? If so, what product security certification should apply?

[OBIvision]

@OBIvision don't worry I'm not Satoshi Nakamoto . Some references: Orange We co-authored the pairing-free version of BBS+ (also called MAC_BBS), see the reference [BBDT16] in our BBS# paper or in the IETF Draft on BBS. BBS# is based on MAC_BBS not on U-Prove

GSMA As you know, the GSMA has published different papers already referenced. In this thread, this one on privacy seems appropriate to recall.

Finally, I think the important part of your message is the "aspects still missing". Would you care to elaborate so that we can improve the proposal ? Thanks a lot in advance.

Hi @ad-Orange,
I am not worried. Statements should be free from authority as authority does not change scientific truths.

I like the BBS# which I think should be adopted urgently (with respect for scrutiny). if you compared it with the Cryptographers feedback, I miss some minor critical issues, e.g. pre-computation credentials.

A major issue is that you cannot build identity in BBS# - we need more and means to combine different technologies, different issuers etc.

The simple test - can this replace ALL (presently surveillance-based) use cases in ARF with trustworthy secure compliant versions - i.e. not depending on or creating personal data.

I understand the GSM-problem. GSM want control in the smartphone for commercial reasons claiming convenience. Problem is of course that you cannot make a smartphone secure (e.g. the BigTech and thus also the FISA problem) so you need main key control OUTSIDE the smartphone in dedicated devices. Except for this most of the arguments are the same.

[sietseringers]

Hi @ad-Orange, thank you for posting your BBS# paper, I have been reading it with much interest. In particular the version that uses ECDSA: if it were possible to use the SE or TEE of existing mobile phones, that would be a great step forward.

However, there is one detail that I don't understand. Each attribute is hashed using $H_i = \mathcal{H}(HID_i \,||\, ID_{a_i} \,||\, a_i \,||\, K_i)$, where $K_i$ is random and unique per attribute, before it is put in the signed credential. Since the RP needs to receive the $K_i$ values of the disclosed attributes in order to be able to verify the disclosure, wouldn't any disclosure of any attribute in both the ECDSA and Schnorr variants break unlinkability?

[ad-Orange]

@sietseringers
Thank you for your feedback.
Regarding the traceability that you mention, it works but... only with the current version of ISO mDL: the salts, in addition to the holder binding public key and the issuer's signatures on the VCs, could indeed be you used to track any user.
We are in fact using constant salts for our ISO mDL compliant version that should be used for all VC issuances carried out by a given IDP (see page 16, footnote 18): "We also assume that the IdP has published n public values (footnote 18), randomly chosen from Zp and denoted {Ki } i=1 n as well as another integer (also public), randomly selected from Zp and denoted as 2ld (for « Undisclosed ») in the following. Footnote 18: These public values will be used for all VC issuances carried out by this IdP." So, these salts won't be helpful to trace a user.
As we said, in page 4, BBS# is also compatible with the ISO/EC 18013-5 standard but it improves it by offering better privacy protection for holders of digital identity credentials (following the ISO/EC 18013-5 format).

[sietseringers]

I see, I missed that, thanks.

But then, why use these salts at all?

• In ISO 18013-5, the point of them is to ensure that the $H_i$ values for any two attributes are always distinct, even if the attributes themselves coincide, so that the $H_i$ don't divulge information about undisclosed attributes. Making these values constant breaks that effect.
• Making them constant is not compliant with ISO 18013-5, which says "This value shall be different for each [attribute]" in §9.2.5.
• They are not necessary in BBS+/#, because in BBS+/# the $H_i$ can be completely hidden from the RP using zero-knowledge proofs, while in ordinary ISO 18013-5 they are part of the MobileSecurityObject so that they are necessarily always all sent to the RP (otherwise the RP won't be able to verify the issuer's signature over the MobileSecurityObject).

As far as I understand the idea was to try to maintain compatibility with ISO 18013-5, but that doesn't really seem feasible to me. Indeed, the cryptographic nature of BBS+/# is so different from ordinary digital signatures on which ISO 18013-5 is based that many of the core data structures of ISO 18013-5 such as the MobileSecurityObject or IssuerSigned won't be usable. Nor would I deem it desirable: BBS+/# solves many things better than plain ISO 18013-5 can, and a BBS+/# implementation would by nature be so different from an ordinary ISO 18013-5 implementation that any kind of interop, which is I would say the point of standards such as these, would be a substantial engineering effort at best.

[ad-Orange]

@sietseringers
For some reason we totally ignore, the commission insisted from the beginning on mDL and SD-JWT.
Already from the first version of the ARF when the ARF was almost empty, that was set in stone. We didn't think it was a good thing at the time and still don't think it is, especially since this choice wasn't made in a transparent way. At all.

Yet, we have to live with it.

That's why we tried and find a solution compatible with it. We think the main compatibility challenge is linked to maintaining the data model whereby a public key is signed by the issuer and the binding is then done with a signature of the corresponding private key.
This is achieved with our proposal. Of course it means accepting other issuer signatures than ECDSA and managing the salts in a different way.
But honestly there is nothing challenging with that and it doesn't change the core of mDL's functioning.
If there is political will, an amendment could be done pretty quickly.
If done this way, the interop would basically mean for the verifier that they need to support some kind of a new profile where the issuer signature is done with BBS#.

[lovesh]

@ad-Orange

One more thing... BBS_Sharp_Short_TR.pdf

Thanks for sharing this. The offline mode (where IdP isn't involved in creating VP) requires use of pairing friendly curve. Thus the SE needs to create signature 𝜎_𝑈𝑠𝑒𝑟 (protocols described in pages 21-24) in a pairing friendly curve. AFAIK, SE on mobile devices (Apple and Android) don't support pairings. So do you imagine such devices to use the "half-online" mode in the short term or is there another way to use offline mode?

We co-authored the pairing-free version of BBS+ (also called MAC_BBS), see the reference [BBDT16] in our BBS# paper

Here is a Rust implementation of BBDT16.
In the light of this new BBS paper, should the MAC in MAC_BBS be the pair (A, e) rather than the triple (A, e, s)

[ad-Orange]

@lovesh

The offline mode (where IdP isn't involved in creating VP) requires use of pairing friendly curve. Thus the SE needs to create signature 𝜎_𝑈𝑠𝑒𝑟 (protocols described in pages 21-24) in a pairing friendly curve. AFAIK, SE on mobile devices (Apple and Android) don't support pairings

No in fact, even in the offline mode (where IdP isn't involved in creating VP), pairings and pairing-friendly curves are not required.
In BBS/BBS+ pairings are used by the RP to check whether the following equality \bar(B) =\hat(A)^{sk_I}, where sk_I is the issuer’s private key (see step 3 of the verification step, page 24), holds or not.
In this technical report, we only described two methods to avoid pairings and pairing-friendly curves (the one described for the HOL mode and the other one described in [BBDT16], where the RP holds the Issuer’s private key).
There are in fact two additional methods to perform this check without using pairings (in addition to the ones described in HOL and BBDT16).
The first one is to let the RP ask the Issuer to check whether this equality (\bar{B} = \hat{A}^sk_I) holds or not. As \hat{A} and \bar{B} have been randomized, the Issuer cannot trace back the holder from these values. Obviously, the Issuer should prove to the RP whether this equality holds or not.
The second one is to let the user pre-provision several “blind” tokens proving that (\bar{B} = \hat{A}^sk) from the Issuer and only use them in the rare cases where both the user and the RP are offline.
So, pairings and pairing-friendly curves are not required for BBS# ; BBS# can therefore be implemented on current SEs. By the way, we implemented BBS# with ECDSA on StrongBox.

Here is a Rust implementation of BBDT16

Great ! Thanks for the Link !

In the light of this new BBS paper, should the MAC in MAC_BBS be the pair (A, e) rather than the triple (A, e, s)

Yes, we used the version described in TZ23 where MAC_BBS is the pair (A, e) rather than the triple (A, e, s).

[lovesh]

@ad-Orange

Thanks for the reply.

The second one is to let the user pre-provision several “blind” tokens proving that (\bar{B} = \hat{A}^sk) from the Issuer and only use them in the rare cases where both the user and the RP are offline.

So the user proactively creates several pairs (\bar{B}, \hat{A}), (in addition to D, r_1, r_2, r_3 for each pair), gets a proof for relation (\bar{B} = \hat{A}^sk) and stores all these to be used later when creating a VP for an RP. The crypto protocol is same as in the HOL mode except here its done proactively (and in a batch for efficiency) whereas its done on-demand in HOL mode.

The first one is to let the RP ask the Issuer to check whether this equality (\bar{B} = \hat{A}^sk_I) holds or not

We support that in our implementation and call the pair (\bar{B}, \hat{A}) a keyed-proof.

[ad-Orange]

@lovesh

So the user proactively creates several pairs (\bar{B}, \hat{A}), (in addition to D, r_1, r_2, r_3 for each pair), gets a proof for relation (\bar{B} = \hat{A}^sk) and stores all these to be used later when creating a VP for an RP. The crypto protocol is same as in the HOL mode except here its done proactively (and in a batch for efficiency) whereas its done on-demand in HOL mode.

Correct.

Thanks again for your interest. Please let us know if you have further questions or suggestions related to BBS#.

[lovesh]

That's all my questions for now. Thank you for your responses.

…

On Wed, Jul 3, 2024, 23:50 ad-Orange ***@***.***> wrote: @lovesh <https://github.com/lovesh> So the user proactively creates several pairs (\bar{B}, \hat{A}), (in addition to D, r_1, r_2, r_3 for each pair), gets a proof for relation (\bar{B} = \hat{A}^sk) and stores all these to be used later when creating a VP for an RP. The crypto protocol is same as in the HOL mode except here its done proactively (and in a batch for efficiency) whereas its done on-demand in HOL mode. Correct. Thanks again for your interest. Please let us know if you have further questions or suggestions related to BBS#. — Reply to this email directly, view it on GitHub <#193 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXYTCJI2RXCYZ5W5ID6QODZKQ6GTAVCNFSM6AAAAABJIVDFSKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBWHE2DANBTG4> . You are receiving this because you were mentioned.Message ID: <eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/193/2206940437 @github.com>

[andrea-dintino]

@ad-Orange landing here from this thread.

Re BBS# we'd like to know if anyone is working on vectors: I couldn't see any vector in the rust imlementation you linked. We're happy to help with that, we implement testing vectors for every crypto scheme we build in our VM (e.g. we use NIST's ML-DSA-44 vectors).

On different topic, we're also happy to see you're advocating for using DIDs in EUDI-ARF. We're collaborating with the EWC consortium who also uses DIDs, at the same time we're working on an EUDI-ARF compatible Identity solution ( DIDroom currently in beta) which also uses DIDs. For that we use our own DID method, mainly as a PKI, that contains multiple public keys, including a BLS381 and a Dilthium2 key (see example).

We'd really appreciate if we could get in touch with someone on both issues :-)

[lovesh]

@andrea-dintino Thanks for your question and the offer to help. There are no test-vectors as of now. On each run, the tests generate random data (keys, messages, MAC).

[eysalee]

Hi @ad-Orange , I'm not sure if this has been brought up in this (or another) thread, but I believe I found a bug in Figure 7 of the BBS# writeup. I've written it up for ease of understanding:
An_attack_on_the_BBS#_Secure_Element_Protocol.pdf
Please correct me if I'm wrong.

Best,
Eysa

[ad-Orange]

Hi @eysalee , thank you for your interest in our work and for sharing your findings on BBS# publicly. Some of your close colleagues have refused to do so which is unfortunate as it prevents wider exchanges on topics that are sometimes difficult to grasp.
I wonder if you read the footnote 28 in our technical report?
Anyway, we are aware of the kind of attacks that you described, which is in fact very similar to the one of Bernhard et al. (Asiacrypt'12, reference [BPW12] in our technical report) against the ECSchnorr signature scheme (when using the weak Fiat-Shamir transformation (wFS)).
To overcome it, Bernhard et al. suggested to use the Strong Fiat-Shamir transformation (sFS) which consists in including, in the hash input, the "statement" to be proved (PK_Blind in our case) in addition to the message (m_2 in our case) to be signed.
In other words, instead of solely hashing the message m_2, the signer should also hash PK_Blind: H(PK^r_2, m_2) instead of H(m_2).
This is exactly this good practice that we propose in footnote 28.
So, by using the sFS (instead of the wFS transformation), as suggested in footnote 28, your attack will not work (as in this case, r_2 will not be equal to (r*H(PK^r_2, m_2))/H(m)).
Do you (or Juraj Sarinay who also seems to think this attack is of importance) think we missed anything ? Please correct us if we're wrong.