--- title: Analysis of Electronic Resident Identity Card proposal author: Ondřej Hladůvka documentclass: extarticle classoption: 10pt geometry: "left=3.5cm,right=3.5cm,top=1cm,bottom=1cm,includeheadfoot" # disable word splitting header-includes: \hyphenpenalty=10000 # references csl: ieee.csl link-citations: true references: - id: rc4 container-title: "RFC 7465 Prohibiting RC4 Cipher Suites" type: report genre: RFC number: 7465 author: Andrei Popov issued: 2015 URL: https://datatracker.ietf.org/doc/html/rfc7465 - id: des container-title: RFC 4772 Security Implications of Using the Data Encryption Standard (DES) type: report genre: RFC number: 4772 author: Scott G. Kelly issued: 2006 URL: https://datatracker.ietf.org/doc/html/rfc4772 - id: rsa-pss container-title: RFC 3447 Public-Key Cryptography Standards (PKCS) \#1 type: report genre: RFC number: 3447 author: Jakob Jonsson and Burt Kaliski issued: 2003 URL: https://datatracker.ietf.org/doc/html/rfc3447#section-8.1 - id: elgamal title: A Public-Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms author: Taher Elgamal container-title: IEEE Transactions on Information Theory volume: 31 issue: 4 page: 469-472 type: article issued: 1985 DOI: 10.1109/TIT.1985.1057074 - id: SHA3 title: "SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash" type: report genre: NIST Special Publication number: 800-185 publisher: National Institute of Standards and Technology (NIST) author: - Kelsey John - Chang Shu-jen - Perlner Ray issued: 2016 URL: https://doi.org/10.6028/NIST.SP.800-185 - id: ecdsa type: report title: Module-Lattice-Based Digital Signature Standard (ML-DSA) collection-title: FIPS 204 publisher: National Institute of Standards and Technology (NIST) issued: 2024 URL: https://doi.org/10.6028/NIST.FIPS.204 - id: luov type: report title: Status Report on the Second Round of the NIST Post-Quantum Cryptography Standardization Process Section 3.24 collection-title: NIST Interagency or Internal Report (NISTIR) 8309 publisher: National Institute of Standards and Technology (NIST) issued: 2020 author: - Alkemade Nicky - Alperin-Sheriff Joel - Apon Daniel - Cooper David - Dang Quynh - Kelsey John - Licht Sean - Liu Yi-Kai - Miller Dustin Moody - Peralta Rene - Perlner Ray - Smith-Tone David - Alagic Gorjan URL: https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8309.pdf - id: clone-attack type: article-journal title: Android Data-Clone Attack via Operating System Customization author: - Song Wenna - Ming Jiang - Jiang Lin - Yan Han - Xiang Yi - Chen Yuan - Fu Jianming - Peng Guojun issued: 2020 container-title: IEEE Access page: 184708–184720 DOI: 10.1109/ACCESS.2020.3035089 URL: https://ieeexplore.ieee.org/document/9246570 - id: owasp-auth type: report title: Authentication Cheat Sheet collection-title: OWASP Cheat Sheet Series publisher: Open Web Application Security Project (OWASP) issued: 2023 URL: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html - id: luov-attack type: article title: "The Nested Subset Differential Attack: A Practical Direct Attack Against LUOV which Forges a Signature within 210 Minutes" author: Beullens Ward publisher: International Association for Cryptologic Research (IACR) collection-title: IACR Cryptology ePrint Archive issued: 2020 URL: https://eprint.iacr.org/2020/967 --- ## Introduction This analysis evaluates proposed e-ID system's compliance agains given criteria. ## Proposed requirements compliance ### The system must manage encryption keys and signing keys securely, including usage of Hardware Security Modules (HSMs) where applicable Not met. Usage of HSM is not even mentioned outside of section 2.2. thus it si certainly not enforced. ### The e-ID data must be encrypted using strong, industry-standard encryption algorithms Not met. Section 2.3 describes encryption of the e-ID credential by the issuer with: DES[@des] and RC4[@rc4] which are insecure. SHA3 which is a hash family[@SHA3], not encryption. RSA-PSS which is signature algorithm[@rsa-pss], not encryption. And ElGamal-OFB which is not a block cipher[@elgamal], thus its not standardized in OFB mode ### The system should rely on use of digital signatures to verify the authenticity of the e-ID data and to ensure that the data has not been tampered with Partially met. LUOV/ECDSA signatures are proposed, but the issuer’s signature on the e-ID is not explicitly verified by RPs. ### The system must ensure that e-ID that was not created by the issuer does not pass verification by the RP Not met. In Presentation protocol step 8 RPs only check for "meaningful plaintext," not issuer signatures, enabling tampering and unauthorised access. ### The system must ensure post-quantum security for all the components Not met. ECDSA is vulnerable to Shors algorithm, as confirming by NIST PQC standardization [@ecdsa]. But its still proposed in both issuing and presentation protocols. ### The system must use standardised cryptographic algorithms Not met. LUOV is not standardized and was rulled out by NIST[@luov]. Voulnabirities was found[@luov-attack] and proposal does not mention any mitigation. DES[@des] and RC4[@rc4] are deprecated. ### The system must ensure that attackers getting access to the user’s device are not able present honest user’s credential to the RP Not met. System lacks device-level authentication or any other second factor, allowing attackers to present credentials. ### The system must ensure strong user authentication before credential is issued Not met. System proposes just photo verification which is weak and unrealiable[@owasp-auth]. No multi-factor authentication is required. ### The system must ensure that adversary cloning the mobile device memory, does not gain access to user’ private information Not met. Private keys arent explicitly stored in HSM, thus they are vulnerable to memory cloning[@clone-attack]. ### The system must ensure that adversary cloning the mobile device memory is not able to issue revocation, issuing and presentation requests (without active participation of user) Not met. Revocation requires no user verification enabling misuse by attackers. ## Additional notes ### Insecure Communication Section 2.2 proposes to send all the information over public communication channel without TLS, this is a critical flaw. ### Offline Revocation Users can self-revoke/modify e-IDs without issuer, risking fraud. ### Unencrypted Cloud Storage Lack of encryption at rest for cloud storage of e-IDs risks data breach. ### Denial of service System do not restrict the number of field in the credentials, risking overload by maliciously large input. ## Conclusion Proposal makes several false claims, proposes usage of deprecated (DES, RC4) as well as experimental ciphers (LUOV). Does not enforce HSM usage, multifactor authentication and data at rest encryption. It also fails at choosing standardised ciphers and does not enforce post-quantum cryptography. And is by design vulnarable to denial of service. **I do not recommend system implementation until these issues are resolved as it would not improve security compared to present system.** \newpage ## References