Open GSMA-EIG opened 2 weeks ago
OBIvision
commented
2 weeks ago 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
ad-Orange
commented
1 week ago One more thing... BBS_Sharp_Short_TR.pdf
OBIvision
commented
1 week ago 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
commented
1 week ago 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
commented
1 week ago @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
commented
6 days ago 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
commented
5 days ago @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.
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:
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.