PosteID: Italian Digital Identity Implementation

• PosteID is the implementation of Italy’s Public Digital Identity System (SPID) using a native Android client integrated with a SAML-based back end.
• It employs heterogeneous cryptographic methods—including AES, RSA-OAEP, and X.509 certificates—to secure device enrollment and authentication.
• A critical vulnerability in OTP binding enabled privilege escalation, prompting coordinated disclosure and subsequent protocol remediation.

Searching arXiv for the specified PosteID paper to ground the article in the cited source. PosteID is the implementation by Poste Italiane of the Italian Public Digital Identity System (SPID) in the identity-provider, or “IdP,” role. In the account analyzed in “The Postman: A Journey of Ethical Hacking in PosteID/SPID Borderland,” PosteID is described as a native Android client coupled to a SAML-based back end, with device enrollment, certificate issuance, and level-based authentication mediated by a set of HTTP(S) REST endpoints. The study documents a vulnerability assessment that uncovered a critical privilege-escalation flaw in the “new device activation” and “strong enrollment” sub-protocols, together with the coordinated disclosure and remediation process that followed (Costa, 22 Jul 2025).

1. System role, trust model, and architectural elements

At its core, PosteID combines a mobile client, a remote identity-provider server, a PKI, and SAML 2.0 service interactions. The Android application package contains a hard-coded symmetric key codk used for bootstrap encryption, generates an asymmetric key pair (appk, ask) locally via javax.crypto and java.security APIs, stores server X.509 certificates, and ultimately forwards SAML AuthnResponse objects to relying parties. The remote PosteID server exposes HTTP(S) REST endpoints such as /registerinit, /register, /activation, /xmobileauth, and /registerapp; it also operates a PKI that issues X.509 certificates both to itself (srv.X509) and to each enrolled device (reg.X509) (Costa, 22 Jul 2025).

The cryptographic layering is explicitly heterogeneous. The initial handshake is encrypted with AES under the hard-coded symmetric key codk. Subsequent messages are encrypted with the server’s RSA public key srvk, for example via RSA-OAEP. The client demonstrates possession of its private key ask by decrypting server responses encrypted under its public key appk. SPID assertions are then exchanged over SAML on the basis of the newly obtained device certificate reg.X509. For level-2, or “strong,” authentication, the design intends to bind an SMS one-time password (OTP) to a device UUID (Costa, 22 Jul 2025).

This arrangement places PosteID at the boundary between mobile application security, protocol design, and federated identity. A plausible implication is that weaknesses in any one of those layers can propagate upward into SPID authentication semantics, because the mobile device certificate becomes the credential by which the client can sign or relay assertions toward SPID service providers.

2. Enrollment and strong-authentication protocol

The paper reconstructs the normal device-registration and privilege-upgrade flow as a concrete sequence of encrypted endpoint invocations. The “new device activation” phase proceeds as follows:

1. Client $\to$ Server: $\mathrm{ENC}_{codk}\{ h(uuid) \}$ via /registerinit
2. Server $\to$ Client: $\mathrm{ENC}_{codk}\{ srv.X509 \}$ with 200 OK
3. Client $\to$ Server: $\mathrm{ENC}_{srvk}\{ h(uuid), appk, fing \}$ via /register
4. Server $\to$ Client: $\mathrm{ENC}_{srvk}\{ app.X509 \}$ with 200 OK
5. Client $\to$ Server: $\mathrm{ENC}_{srvk}\{ * \}$ via /activation
6. Server $\mathrm{ENC}_{codk}\{ h(uuid) \}$0 Client: 200 OK

After step 6, the device possesses a valid client certificate but only level-0 privileges. To obtain level 2, the client performs the following “strong enrollment” sequence:

1. Client $\mathrm{ENC}_{codk}\{ h(uuid) \}$1 Server: $\mathrm{ENC}_{codk}\{ h(uuid) \}$2 via GET /xmobileauth
2. Server $\mathrm{ENC}_{codk}\{ h(uuid) \}$3 Client: 200 OK
3. Client $\mathrm{ENC}_{codk}\{ h(uuid) \}$4 Server: $\mathrm{ENC}_{codk}\{ h(uuid) \}$5 via GET /xmobileauth 10. Server $\mathrm{ENC}_{codk}\{ h(uuid) \}$6 Client: 200 OK + SMS(otp)
4. Client $\mathrm{ENC}_{codk}\{ h(uuid) \}$7 Server: $\mathrm{ENC}_{codk}\{ h(uuid) \}$8 via GET /xmobileauth
5. Server $\mathrm{ENC}_{codk}\{ h(uuid) \}$9 Client: $\to$0 with 200 OK
6. Client $\to$1 Server: $\to$2 via POST /registerapp
7. Server $\to$3 Client: $\to$4 with 200 OK

In the SPID high-level SAML flow, PosteID eventually issues an AuthnResponse signed by reg.X509, which the mobile app forwards to a service provider via browser or embedded WebView (Costa, 22 Jul 2025).

The protocol is therefore not merely a mobile login procedure. It is the mechanism by which a device becomes an authorized SPID authenticator for a user account. That distinction is important for understanding the impact of the flaw: compromise of enrollment semantics is equivalent to compromise of the user’s authenticated device identity.

3. Privilege-escalation vulnerability and exploit chain

The paper identifies the weakness in the interaction between “new device activation” and “strong enrollment.” The attack surface includes all endpoints under /register*, /xmobileauth, and /registerapp, the hard-coded key codk in the APK, the Android SMS listener API, and the device-management API that allows deregistration of existing devices (Costa, 22 Jul 2025).

The exploit sequence is described in four stages. First, a Trojan performs a fake “new device” registration: it extracts codk from the legitimate APK, generates a random uuid′, constructs fing′ from public device data, and repeats steps 1–6 of the normal protocol to obtain a separate app.X509′. Second, it performs fake strong authentication: using stolen basic credentials (usr, pwd), it executes steps 7–10 for uuid′, intercepts the SMS OTP because it has READ_SMS permission, and submits step 11 with {lvl=2, otp, uuid′} to obtain token′. Third, it hijacks the account by calling /registerapp with {token′, pid} and receiving reg.X509′, which gives the Trojan a valid level-2 certificate for the victim’s account. Fourth, it invokes the device-management endpoint, for example /deleteDevice, using token′; because the server grants full level-2 rights to that token, the real device can be remotely deregistered, leaving the Trojan as the only remaining authorized client (Costa, 22 Jul 2025).

Once the Trojan controls the only registered device, it can sign SAML assertions at will, access any SPID-protected service, and even initiate monetary transactions on Poste Italiane bank accounts. The flaw is therefore categorized as a critical privilege escalation in the paper’s abstract, and the proof-of-concept exploit was assigned a proposed CVSS 8.7, later revised to 8.3 during the disclosure process (Costa, 22 Jul 2025).

A common misconception in systems of this type is that SMS OTP automatically provides an independent second factor. The case described here directly contradicts that assumption under the attacker model considered in the paper: when the device itself is compromised, the SMS channel is no longer operationally independent.

4. Root cause: missing binding between OTP challenge and device identity

The paper’s root-cause analysis isolates a logic flaw rather than a failure of the underlying cryptographic primitives. The intended security invariant is stated as

$\to$5

In the implemented system, however, the server accepted any (otp, uuid) tuple so long as the OTP matched one of the outstanding challenges for the user, regardless of which uuid had initiated the GET /xmobileauth(lvl=2) call. The formal characterization given in the paper is

$\to$6

but

$\to$7

because the server failed to enforce

$\to$8

The decisive defect is therefore the absence of server-side binding between the OTP challenge and the original device UUID. In effect, the system verified possession of a valid OTP for the user but did not verify that the OTP corresponded to the same device identity for which the level-2 upgrade was requested. This allowed an attacker-in-the-device to enroll an arbitrary second uuid′, intercept the OTP sent to the real device, and replay it for uuid′ (Costa, 22 Jul 2025).

This suggests a broader protocol-design principle: if a factor is intended to authorize a particular session, device, or transaction context, that context must be represented explicitly in the server state and checked at verification time. Merely issuing a correct OTP is not sufficient if the verifier does not preserve and test the associated binding.

5. Remediation and protocol changes

The remediation is presented in two layers: immediate mitigation and definitive protocol repair. The short-term measures were operational controls. PosteID disabled the remote device-deregistration API for any newly enrolled device until manual review and limited the maximum number of concurrent registered devices per user to one (Costa, 22 Jul 2025).

The long-term fix modified /xmobileauth so that the OTP became cryptographically bound to the device UUID in server state. The paper gives the following simplified server-side pseudocode diff:

$\to$9

In addition, the client APK was updated so that the final GET /xmobileauth({lvl=2, otp, uuid}) is always encrypted under srvk and includes an HMAC under ask as extra integrity. PosteID then rolled out a new Android application version in March 2025 and incremented the SPID metadata “certificate” fingerprint so that old code could no longer interoperate (Costa, 22 Jul 2025).

These changes are notable because they combine protocol-state repair, client-message hardening, and ecosystem-level compatibility control. A plausible implication is that the fix was designed not only to reject the specific exploit sequence but also to prevent downgrade or partial-interoperability paths involving legacy client behavior.

6. Coordinated disclosure, timeline, and lessons

The paper presents the episode as a coordinated disclosure case study. The timeline is given as follows:

Date	Event
October 2023	Formal engagement with Poste Italiane, scope definition
October 2023–May 2024	Static/dynamic analysis; discovery of the OTP binding flaw
May 2024	Proof-of-Concept exploit completed; CVSS 8.7 initially proposed, later 8.3
June–September 2024	Meetings to demonstrate the exploit, propose countermeasures, and negotiate patch timeframe
March 2025	Final PosteID vX.Y release with the permanent fix

The communication channels included encrypted email for vulnerability details and proof-of-concept code, monthly in-person or remote presentations to the Security, DevOps and Legal teams of Poste Italiane, and liaison with AgID to ensure SPID compliance (Costa, 22 Jul 2025).

The lessons extracted in the paper are framed for both ethical hackers and vendors. Protocol design reviews and threat modeling, including AidD scenarios, are described as being as crucial as code review. Out-of-band factors such as SMS and email are explicitly characterized as not truly independent when the device itself is compromised. Security invariants, including the binding of challenges to sessions or device IDs, are said to require explicit statement, implementation, and testing. Obfuscation is said to delay but not prevent protocol-level reverse engineering when dynamic slicing is used. Finally, responsible disclosure is described as remaining ad hoc, and the paper argues that formal standards for timelines and scope would help SMEs handle security research more effectively (Costa, 22 Jul 2025).

Within the PosteID/SPID setting, the broader significance lies in the way the case connects mobile malware capabilities, enrollment logic, and federated identity assurance. The paper’s closing rationale is that sharing the complete attack narrative, root cause, remediation steps, and disclosure timeline may help other SPID IdP operators, and the wider authentication community, avoid similar pitfalls (Costa, 22 Jul 2025).