TalTech_crypt/hw4/reseni.md

---
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
---
 <!-- Does the system proposed in the paper satisfy all the stated system requirements Provide a short explanation and reasoning for each requirement. -->

<!-- Identify if there are additional inconsistencies in the system or in the system description -->

<!--Provide conclusion, summarising if the system should be implemented as a real-life project. -->

## Introduction
This analysis evaluates proposed e-ID system's compliance agains given criteria.


## Proposed requirements compliance

<!-- done -->
### 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.

<!-- done -->
### 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

<!-- done -->
### 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.

<!-- done -->
### 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.

<!-- done -->
### 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.

<!-- done -->
### 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.

<!-- done -->
### 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.

<!-- done -->
### 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.

<!-- done -->
### 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].

<!-- done -->
### 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 <!-- inline latex commands :3 -->
## References
<!-- these will be generated automatically by citeproc -->