Emancipation from Google's ASN.1 Parsing Logic

[JesusMcCloud]

Currently, we incorporate abandoned, buggy upstream code from Google.
Instead we should have Signum do the parsing properly, i.e. type-safe, smooth to use, more fault-tolerant but without sacrificing security guarantees.

This would not only rid us from dependencies and technical debt, but would give us a fully-featured, proper attestation statement generator for free, far beyond the already very handy work of @nodh in the test sources.

[ismail-s]

@JesusMcCloud Hi, just an FYI - android-key-attestation recently got deprecated in favour of the new keyattestation repo.

[JesusMcCloud]

Thanks, we're tracking that!

###TL;DR

As of now, this code is still not as fault-tolerant as we'd like it to be, while at the same time providing less logic when it comes to fully parse data that is actually schema-compliant. We're still figuring out how to go forward.

Long version

Let me provide an example about what this means in practice:

Let's say my service relies on attestation, because I absolutely must guarantee that users' private keys are stored in hardware, as to never have them exposed. At the same time, I don't really care all that much for vendorPatchLevel and some other properties, as long as I check everything I need to check to ensure that users' private keys are safely stored in hardware before granting them access to my service.
While Google's new code can handle the single zero value inside vendorPatchLevel that some Android 15 phones produce, it will still throw an exception if vendorPatchLevel contains an empty OCTET STRING, for example. The mere fact of a single property being structurally invalid has no impact on any property inside the attestation extension and my service doesn't even care. At the same time, users with phones that are perfectly capable of protecting keys in hardware won't be granted access due to a malformed property nobody cared about.

Would the new Google code contain lazy properties instead of eagerly evaluating everything, we could get there. Right now it doesn't. Moreover, device manufactures tend to get pretty creative when it comes to messing up attestation and this isn't going to suddenly stop. So what you really want is an either-type for each property:

• correctly encoded: get the value
• borked encoding: contains an exception with a full stack trace showing exactly where, how, and why decoding failed, and the raw ASN.1 bytes that caused the exception.

As a service operator, you really want the kind of debug information only an exception with a stack trace can give you, but you don't want the whole parsing to fail hard: Let's say, I start to care for vendorPatchLevel at some point. Users will get errors, and I will get support requests. I have the full error info on a per-property basis thanks to the fancy either type. It will take me less than 90 seconds to figure out what's going on and I can respond to support requests (and blame the phone manufacturer). If I use Google's parser (old or new), I need to re-trace all steps using an attached debugger and a recorded attestation proof submitted by a user and it will take much more time, because I don't immediately see where, how, and why parsing failed. So I need to do this for every single support request, to individually check whether the issue lies with the user's phone, Warden, or my service back-end, as I don't even know whether it's the same issue or something different entirely -- and on top of it the new code places the burden of decoding values according to the attestation schema on Warden.
This whole take is not just theoretical but based on inquiries and feedback from services being run on a national scale that rely on Warden. Those are real pain points and we've spent tedious hours debugging, sifting through logs, examining raw bytes of attestation statements, feeding them into ASN.1 parsers, manually matching them against the attestation schemas to finally figure out what's what.

Google are relying on attestation themselves so it is safe to assume that the new code they published has already been rolled out in production for some of their internal services, replacing the old code. Maybe it was even fully replaced by the time the new code was published. Who knows… Bottom line is: Now that Google published their new code, its safe to assume it will pretty much stay the way it is. Of course, it will be maintained, updated and gradually improved, but I'm not betting on any of the fundamental changes required to get to the point I illustrated above. Maybe they can be pursued to go for lazily evaluating properties. That would already be enough to make the new code a viable upgrade path.

At the moment, everything's still very much in flux and we don't have a definitive strategy on how to go forward. Most likely, the low-level ASN.1 parsing will be done by Signum (as currently in development here and here for all the fine-grained debugging capabilities, while the PKI stuff will rely on the new Google code.