The scope of 18013-5 states:
The following items are out of scope for this document:
— requirements on storage of mDL data and mDL private keys.
Clause E.13 mDL holder (user) authentication from 18013-5 mentions:
Unlocking and use of the mDL should only be permitted with appropriate mDL holder authentication proving
that the user is the intended mDL holder.
Although necessary, this is insufficient, in particular when an mDL holder is accepting to collude with another individual to perform all the cryptographic computations the other individual needs to access to a verifier, without disclosing a set of attributes that allows to identify the holder and when unlikable mdocs are used (see #38).
In OID4VP, the nine sub-clauses from Clause 14 (Security Considerations) do not address this issue.
Preventing the export of mDL private keys to insecure environments is a necessary but insufficient condition. Providing an interface to a physical component (e.g. a TPM) that allows to perform digital signatures using mDL private keys stored in that physical component does not guarantee
that the calling application is a 'legitimate' application. The same applies, if mDL private keys are stored in the Cloud.
A verifier needs to be convinced that the mdoc app used by a holder is "secure".
It means that the mDL private keys must only be used by one or more mdoc apps that has been certified by a trusted laboratory (TTP)
which can testify that they support a specific set of features.
This can be done using mdoc app attestations.
Supporting a protocol between an mdoc app and a verifier to demonstrate that the mdoc app supports a specific set of features would not permit
to support the unlinkability property between verifiers. This is why such a protocol is not desirable.
Transitive trust should be used instead.
The mdoc app first demonstrates to the issuer that it supports a specific set of features, by using an mdoc app attestation.
Then after, the issuer includes into each mdoc the identity of the trusted laboratory that has delivered the mdoc app attestation according to some security profile, as well as the specific set of features supported by the mdoc, making sure that any information that might uniquely identify an mdoc app is not copied into the mdoc.
Can the current documents (i.e. 18013-5 and OID4VP) supports this requirement ? Unfortunately, the answer is no.
- Regardless of the format used for the mdoc, a field capable of containing the aforementioned information must be present.
It has not yet been defined.
- Security profiles to certify mdoc apps are not yet available. Some security profiles are in preparation by ENISA
(European Network Information Security Agency).
ENISA has a mandate from the EC to define and launch a security certification scheme for EUDI wallets, according to
the Implementing Act 2024/2981 which states:
- providers of wallet solutions (…) should define and implement processes to evaluate the severity and potential impact of vulnerabilities.
- the security requirements necessary to address the cybersecurity risks and threats listed in the risk register set out in Annex I of this Regulation,
up to the required assurance level, and to meet, where applicable, the objectives defined in Article 51 of Regulation (EU) 2019/881.
Unfortunately, Regulation (EU) 2019/881 of 8 September 2015 only sets out minimum technical specifications and procedures for assurance levels for electronic identification. The risk register from Regulation (EU) 2024/2981 does NOT identify user collusion attacks since they do not occur in the context of electronic identification when the identification of the user is required.
A large majority of smart-phones supports a TEE (Trusted Execution Environment). Such TEEs can host one or more Trusted Applications (TAs).
These TAs are running under a TrustedOS and can be called by one or more Untrusted Applications (UAs) running under a RichOS.
When a TA receives a call from a UA, it shall be able to make sure that this UA is a 'legitimate' UA and that it has not latter been modified in case the mobile device has been jailbroken (iOS) or rooted (Android).
A clause identifying threats arising from collaborative attacks or collusion between users, as well as mitigation measures should be added into the draft.
The scope of 18013-5 states:
Clause E.13 mDL holder (user) authentication from 18013-5 mentions:
Although necessary, this is insufficient, in particular when an mDL holder is accepting to collude with another individual to perform all the cryptographic computations the other individual needs to access to a verifier, without disclosing a set of attributes that allows to identify the holder and when unlikable mdocs are used (see #38).
In OID4VP, the nine sub-clauses from Clause 14 (Security Considerations) do not address this issue.
Preventing the export of mDL private keys to insecure environments is a necessary but insufficient condition. Providing an interface to a physical component (e.g. a TPM) that allows to perform digital signatures using mDL private keys stored in that physical component does not guarantee
that the calling application is a 'legitimate' application. The same applies, if mDL private keys are stored in the Cloud.
A verifier needs to be convinced that the mdoc app used by a holder is "secure".
It means that the mDL private keys must only be used by one or more mdoc apps that has been certified by a trusted laboratory (TTP)
which can testify that they support a specific set of features.
This can be done using mdoc app attestations.
Supporting a protocol between an mdoc app and a verifier to demonstrate that the mdoc app supports a specific set of features would not permit
to support the unlinkability property between verifiers. This is why such a protocol is not desirable.
Transitive trust should be used instead.
The mdoc app first demonstrates to the issuer that it supports a specific set of features, by using an mdoc app attestation.
Then after, the issuer includes into each mdoc the identity of the trusted laboratory that has delivered the mdoc app attestation according to some security profile, as well as the specific set of features supported by the mdoc, making sure that any information that might uniquely identify an mdoc app is not copied into the mdoc.
Can the current documents (i.e. 18013-5 and OID4VP) supports this requirement ? Unfortunately, the answer is no.
It has not yet been defined.
(European Network Information Security Agency).
ENISA has a mandate from the EC to define and launch a security certification scheme for EUDI wallets, according to
the Implementing Act 2024/2981 which states:
up to the required assurance level, and to meet, where applicable, the objectives defined in Article 51 of Regulation (EU) 2019/881.
Unfortunately, Regulation (EU) 2019/881 of 8 September 2015 only sets out minimum technical specifications and procedures for assurance levels for electronic identification. The risk register from Regulation (EU) 2024/2981 does NOT identify user collusion attacks since they do not occur in the context of electronic identification when the identification of the user is required.
A large majority of smart-phones supports a TEE (Trusted Execution Environment). Such TEEs can host one or more Trusted Applications (TAs).
These TAs are running under a TrustedOS and can be called by one or more Untrusted Applications (UAs) running under a RichOS.
When a TA receives a call from a UA, it shall be able to make sure that this UA is a 'legitimate' UA and that it has not latter been modified in case the mobile device has been jailbroken (iOS) or rooted (Android).
A clause identifying threats arising from collaborative attacks or collusion between users, as well as mitigation measures should be added into the draft.