In our analysis, we focus on the marked area.

​

Challenge 1 – key management

 

SIOPv2 requires the Relying Party (RP) to authenticate token IDs using signature verification.

SIOPv2 -  Self-Issued OpenID Provider v2 - draft 13

​

11.1. Self-Issued ID Token Validation

 

To validate the ID Token received, the RP MUST do the following:

 

4. The RP MUST validate the signature of the ID Token. When Subject Syntax Type is JWK Thumbprint, validation is done according to JWS [RFC7515] using the algorithm specified in the alg header parameter of the JOSE Header, using the key in the sub_jwk Claim.

​

Reference is made to RFC 7515 - JSON Web Signature (JWS) - RFC 7515: JSON Web Signature (JWS) (rfc-editor.org)

RFC 7515 describes the consequences of missing key management used for signing.

​

10.  Security Considerations

10.3.  Key Origin Authentication

​

The key management technique employed to obtain public keys must authenticate the origin of the key; otherwise, it is unknown what party signed the message.

​

Likewise, the key management technique employed to distribute MAC keys must provide data origin authentication; otherwise, the contents are delivered with integrity from an unknown source.

 

For example, the attacker Bob obtained a copy of the ID token of the victim Alice. If Bob signs Alice's ID token with his private key and uses it when communicating with the RP, the RP will verify the validity of the signature successfully and will not detect that the ID token has been forged.

Key management is not described, let alone implemented and validated.

 

Authentication deadlock?

​

The reference architecture describes the purpose of the EUDI Wallet:

„The primary purpose of the EUDI Wallet is to offer secure identification and authentication of users at a high Level of Assurance (LoA) for both public and private online services. This essential functionality ensures that Relying Parties can confidently verify that they are interacting with the correct User.“

In contrast, SIOPv2 requires the Relying Party (RP) to perform ID token authentication. In order for it to be secure, RFC 7515 requires: „must authenticate the origin of the key“. 

Thus, in order for the RP to use the EUDI Wallet to authenticate the user, the RP must verify the signature of the ID token and therefore „must authenticate the origin of the key“ with which the ID token is signed. Authentication requires authentication.

​

Challenge 2 – cryptographic agility

​

RFC 7515, referring to RFC 7518, also mentions another security feature of the cryptography used. Obsolescence of cryptographic algorithms.

RFC 7515: JSON Web Signature (JWS) (rfc-editor.org)

​

10.  Security Considerations

10.4.  Cryptographic Agility

 

See Section 8.1 of [JWA] for security considerations on cryptographic agility.

 

RFC 7518: JSON Web Algorithms (JWA) (rfc-editor.org)

​

8.1.  Cryptographic Agility

 

Implementers should be aware that cryptographic algorithms become weaker with time.  As new cryptanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will be reduced.  Therefore, implementers and deployments must be prepared for the set of algorithms that are supported and used to change over time.  Thus, cryptographic algorithm implementations should be modular, allowing new algorithms to be readily inserted.

 

Using eID and EUDI Wallet is a long-term issue. It can be expected that the performance of computers will increase during the human lifetime and there will be many innovations in cryptographic algorithms. E.g. significant changes can be expected in connection with the development of quantum computers and quantum-resistant algorithms.

 

Challenge 3 – Data channel binding

​

Both OpenID4VP and SIOPv2 describe a possible attack resulting from the lack of linking of transmitted data with the used data channel.

OpenID4VP - OpenID for Verifiable Presentations - draft 20

​

12. Security Considerations

​

12.2. Session Fixation

​

To perform a Session Fixation attack, an attacker would start the process using a Verifier executed on a device under his control, capture the Authorization Request and relay it to the device of a victim. The attacker would then periodically try to conclude the process in his Verifier, which would cause the Verifier on his device to try to fetch and verify the Authorization Response.

Such an attack is impossible against flows implemented with the Response Mode fragment as the Wallet will always send the VP Token to the redirect endpoint on the same device where it resides. This means an attacker could extract a valid Authorization Request from a Verifier on his device and trick a Victim into performing the same Authorization Request on her device. But there is technically no way for an attacker to get hold of the resulting VP Token.

However, the Response Mode direct_post is susceptible to such an attack as the result is sent from the Wallet out-of-band to the Verifier's Response Endpoint.

SIOPv2 - Self-Issued OpenID Provider v2 - draft 13

​

13. Security Considerations

 

13.3. Usage of Cross-Device Self-Issued OP for Authentication

​

A known attack in cross-device Self-Issued OP is an Authorization Request replay attack, where a victim is tricked to send a response to an Authorization Request that an RP has generated for an attacker. In other words, the attacker would trick a victim to respond to a request that the attacker has generated for him/herself at a good RP, for example, by showing the QR code encoding the Authorization Request that would normally be presented on the RP's website on the attacker's website. In this case, the victim might not be able to detect that the request was generated by the RP for the attacker. (Note that the same attack applies when methods other than a QR code are used to encode the Authorization Request. For brevity, only the QR code method will be discussed in the following, but the same considerations apply to other transport methods as well.)

This attack is based on the fact that the Authorization Request is not tied to a specific channel, i.e., it can be used both in its original context (on the RP's website) as well as in a replay scenario (on the attacker's website, in an email etc.). Such a binding cannot be established across devices with currently deployed technology. Therefore, in the cross-device protocol flow, the contents transported in the authentication (including any Verifiable Presentations) are not wrong, but do not necessarily come from the End-User the RP website thinks it is interacting with.

Let us remind you that it is in the power of the attacker to change same-device flow to cross-device flow, e.g. by means of a MITM attack in which the attacker can also control DNS (e.g. control of a Wi-Fi access point). And there are other consequences, such as Challenge 5.

​

Challenge 4 - Advanced dynamic authentication

​

OpenID4VP describes the need for replay attack protection - OpenID for Verifiable Presentations - draft 20

 

12. Security Considerations

 

12.1. Preventing Replay of the VP Token

 

An attacker could try to inject a VP Token (or an individual Verifiable Presentation), that was obtained from a previous Authorization Response, into another Authorization Response thus impersonating the End-User that originally presented that VP Token or the respective Verifiable Presentation.

Implementers of this specification MUST implement the controls as defined in this section to detect such an attack.

SIOPv2 requires the RP (Client) to perform nonce verification and reply attack detection. But it does not describe the method of detection and leaves it to individual implementation.

 

SIOPv2 - Self-Issued OpenID Provider v2 - draft 13

 

11.1. Self-Issued ID Token Validation

​

To validate the ID Token received, the RP MUST do the following:

​

7. The RP MUST validate that a nonce Claim is present and is the same value as the one that was sent in the Authorization Request. The Client MUST check the nonce value for replay attacks. The precise method for detecting replay attacks is RP specific.

 

Replay attack detection is a standard dynamic authentication task. It is resolved, for example, in http Digest Access Authentication RFC 2069.

​

The reference architecture describes the purpose of the EUDI Wallet:

​

The primary purpose of the EUDI Wallet is to offer secure identification and authentication of users at a high Level of Assurance (LoA) for both public and private online services

​

eIDAS requires dynamic authentication starting at the Substantial level.

​

Let us recall the eIDAS requirements for High Level of Assurance: The authentication mechanism implements security controls for the verification of the electronic identification means, so that it is highly unlikely that activities such as guessing, eavesdropping, replay or manipulation of communication by an attacker with high attack potential can subvert the authentication mechanisms.

 

 

Challenge 5 - Protection against copying wallet content

​

The keys and person identification data (PID) used must be protected against copying by an attacker. If an attacker got hold of a copy of these keys and/or PIDs, they could successfully exploit them and impersonate the victim.

The issue of protection is described only indirectly and incompletely. In the reference architecture, the use of WSCD is implicitly required:

​

2 Definitions

 

Wallet Secure Cryptographic Device (WSCD)* : Hardware-backed secure environment for creating, storing, and/or managing cryptographic keys and data. Examples include Secure Elements (SE), Trusted Execution Environments (TEEs), and (remote or local) Hardware Security Module (HSM).

 

This is a wide range of options with very different security implications.

​

E.g. when using a smart card (SE), it is not easy to store the PID on the smart card, and the smart card is another device. Therefore, it is necessary to use "the cross-device protocol flow", which brings the risk of the attack described in Challenge 3.

​

The HSM is also a different device, and it's also a shared device. When using other shared HW, an authentication deadlock occurs. In order to be able to use the keys and obtain data to perform authentication using the EUDI Wallet, it is necessary to perform authentication that allows the authorized user using the Wallet to use the keys and PIDs protected by the HSM and prevent an attacker from using the HSM. This is an authentication deadlock.

​

Hardware devices have a limited lifespan and can fail. This brings up another challenge (Challenge 7).

 

Challenge 6 - Key rotation

​

Key security is not permanent. Therefore, the keys are used securely only for a limited time.

E.g. an agreement between CAs reduced the validity period of server TLS/SSL certificates to about 13 months in 2020:

​

How Long are TLS/SSL Certificate Validity Periods? | DigiCert FAQ

 

TLS/SSL Certificate Validity Periods are currently 398 days, or about 13 months. They were recently reduced by the CA/B Forum starting Sept. 1, 2020 in response to Apple’s announcement stating they would not accept certificates for two-year validity periods.

The period of use of the EUDI Wallet should be longer than several months, i.e. the keys used should rotate.

 

 

Challenge 7 - Replacement of EUDI Wallet hardware, redundancy

​

With long-term use, additional requirements arise that conflict with the requirement for copy protection and WSCD properties.

Standard requirements for security hardware are, for example, that it must not allow reading or writing of the private key. But it allows the private key to be used, for example, to sign data.

Every device sometimes becomes obsolete and is replaced by a new, more modern one. Any device can break down, be destroyed or stolen.

​

How is the functionality of the EUDI Wallet to be ensured even in such situations with acceptable security?

 

Other challenges

​

The analysis did not cover the entire scope of the architecture and did not go into all the details. There are still other challenges. For example:

• there is another area in the architecture where authentication deadlock occurs,

• the issue of linking the Wallet owner with the PID subject,

• mutual authentication,

• DID security, e.g. security risks associated with the use of a potentially faked DID document,

• conflict between OpenID Connect Core 1.0 and SIOPv2 standards.

 

 

Conclusion

 

Instead of concluding, let's quote the Disclaimer of the EUDI Wallet reference implementation:

Disclaimer

• The initial development release has reduced security, privacy, availability, and reliability standards relative to future releases. This could make the software slower, less reliable, or more vulnerable to attacks than mature software.

• We strongly recommend not putting this version of the software into production use.

• ​

Personal opinion of the author:

​Using OpenID4VP, SIOPv2 and also OpenID4VCI is wrong choice from the point of view of the architecture of ICT systems. Everything is based on OAauth and OIDC, which are standards that do not deal with user authentication, but only deal with the transfer of authentication and authorization results between systems.