Permanent Identity Compromise

The "Permanent Identity Compromise" problem extends far beyond a simple credential theft. In systems based on static cryptography (Scenario A), the private key becomes the digital equivalent of a citizen’s DNA. Once extracted from a secure processor (e.g., via TEE implementation flaws), it allows an attacker to generate legally binding declarations of intent that are indistinguishable from the victim's actions.

Dr. Janusz Jabłoński Cryptography Expert

Attack Model: "Permanent Identity Compromise"

1. Attack Objective

Unauthorized authentication as a citizen in a critical service (e.g., taking out a loan, selling real estate) by compromising cryptographic material from a mobile device.

2. Scenario A: Current mObywatel Architecture (Static ECC/RSA Key)

  • Attack Vector: Exploitation of a Zero-Day vulnerability in the secure processor (Secure Enclave/TEE) or a Side-Channel attack (analysis of electromagnetic emissions/power consumption during the signing process).

  • Execution:

    1. The attacker extracts the private key (or forces the module to sign arbitrary challenges without the user's knowledge).

    2. Because the Private Key is static and linked to the identity for years, every subsequent "challenge" from the e-PUAP/banking system can be signed by the attacker.

  • Result: Total and permanent identity compromise. The citizen is unaware that their "identity key" has been duplicated until it is revoked in state registries.

  • eIDAS Compliance: The system fails regarding "data attribution," as a static key in the hands of a hacker is indistinguishable from the key in the hands of the citizen.

3. Scenario B: Proposed RSA-OTP / Hash Chain Architecture

  • Attack Vector: Identical to the above—full device compromise and access to operational memory.

  • Execution:

    1. The attacker gains access to the current element of the chain, $H_n$.

    2. The attacker attempts to use $H_n$ for authentication.

    3. Defense Mechanism: The moment $H_n$ is used by the attacker, it is "burned" (one-time use). If the legitimate user attempts to log in using the same "key," the system detects a discontinuity in the chain.

    4. The attacker cannot generate $H_{n-1}$ (the previous element) or $H_{n+1}$ (future elements) without knowledge of the "initial contact" data.

  • Result: The attack is limited to one specific transaction. The attacker does not hijack the "identity" itself, but only a single "entry ticket."

  • eIDAS Compliance: Meets the requirement for "dynamic data." Even if data from one session is leaked, it remains useless for any subsequent sessions.