ios – How do you extract the `nonce` (problem) from an Apple App Attest CMS/PKCS7 receipt on the server aspect?

HOW TO EXTRACT NONCE FROM APPLE ATTEST CMS RECEIPT?

I am engaged on a server implementation to validate Apple’s iOS machine App Attest protocol, particularly validating the attestation (receipt) on the server.

Context

The iOS shopper makes use of to create an attestation object:

DCAppAttestService.shared.generateAssertion(...)

Getting the Receipt

This object is shipped to server as base64 string. It’s then decoded to binary after which to CBOR. The receipt area is then discovered at cborData[“attStmt”][“receipt”].

What’s the Receipt?

This receipt is a PKCS#7 SignedData (CMS) construction.

Utilizing Rust (with crates like cms, der-parser, x509-parser, and many others.), I can efficiently:

• Decode the receipt from base64
• Parse the outer PKCS#7 SignedData container
• Extract the embedded eContent (EncapsulatedContentInfo)

What’s the embedded information???

Contained in the embedded information, we anticipate there needs to be the nonce (aka challengePassword, OID 1.2.840.113549.1.9.7). Nonetheless, I can’t attain it or determine tips on how to discover it inside there.

Right here we are actually caught. The eContent area accommodates a binary ASN.1 blob that can’t be decoded utilizing any recognized ASN.1 decoder (OpenSSL, der-parser, asn1crypto, and many others.).

Key points:

• The binary blob seems to make use of BER encoding with indefinite-length fields.

• It’s not legitimate DER, which causes parsers to fail or return partial outcomes.

• Even when making an attempt fallback parsing or decoding the blob as CBOR, I both get a meaningless construction or cannot attain the nonce.

• The nonce (aka clientDataHash or challengePassword) is meant to be current as OID 1.2.840.113549.1.9.7, however:

  • It’s not discovered reliably
  • The ASN.1 construction is undocumented and nested deeply

• It isn’t documented by Apple

• It isn’t legitimate DER (it is BER with indefinite size)

• Can’t be parsed by Rust’s der-parser, x509-parser, or ciborium

• Fails when parsing as a DER SET or SEQUENCE

• Can’t be interpreted and not using a construction definition

What I’ve Tried

• Extracting eContent from the CMS envelope
• Parsing with der-parser, ciborium, and fallback uncooked parsing
• Tried CBOR decoding simply in case (some values seem like CBOR integers)
• Checked for all OIDs contained in the blob, however can’t discover the anticipated problem information
• Tried OpenSSL asn1parse on the DER – fails with “too lengthy” or “invalid size”
• In contrast with examples from GitHub and Apple’s documentation, however no formal ASN.1 spec is accessible

Why This Issues

I am avoiding extracting the problem on the shopper (iOS) as a result of that will make the server blind to potential replay assaults – the entire level of server-side attestation is to make sure the problem was freshly signed by Apple and obtained immediately from the shopper.

With out accessing the nonce within the payload, I can’t affirm the shopper signed the problem I despatched – which means the attestation is not full.

What I Want

• Is there any official or unofficial ASN.1 specification for this Apple receipt format?
• Has anybody efficiently extracted the nonce (clientDataHash) from a SignedData payload on the server with out utilizing Apple platform APIs?
• Or – can we must deal with the receipt as opaque and rely solely on signature validation?

Context

• Rust stack utilizing cms, der, der-parser, x509-parser, and many others.
• No entry to Apple platform code on the server (Linux host)
• Wish to confirm the nonce with out trusting the shopper to replicate it

Thanks for any assist!