Forem: Matt Nelson-White

Implementing Apple's Device Check App Attest Protocol

Matt Nelson-White — Wed, 12 Jul 2023 13:15:01 +0000

When creating a back-end for your App, you may want to secure your API so that you can ensure that the App cannot be used by agents other than legitimate APP installs running on legitimate devices. This lowers the API attack surface by limiting exposure to only legitimate APP installs.

As developers, APIs are often protected by user authentication and authorisation; but in instances where there is no user authentication your API is left unprotected.

Suggestions on many forums, that APIs can be protected by configuring your APP with a secret "API Key", are sub-optimal since it is essentially "security by obfuscation" (the secret can be retrieved by extracting it from your APP package).

The answer to both, "how can I secure my API from illegitimate clients? ", and "how should I protect unauthenticated clients?", is "App Attestation"! 🎉🥳

Apple and Android have solutions for App Attestation, but this article will be focused on Apple's Device Check App Attest.

Basic Flow

The figure taken from the App Attest "Establishing Your App's Integrity" document shows there are three high-level components involved in App Attest;

your app,
your server,
and the app attest service.

There is a little more involved than that, and a little more that is useful to know about the high-level components.

Critically, the "App Attest" service, as it is shown in the figure above, is an internet-exposed service, which may fail or timeout from time to time.

Furthermore, the Secure Enclave on the device is used to prevent "Your App" from direct access to the private key generated for the use of App Attest.

Your server delivers a string of random bytes which represents a challenge to your app.
Your app creates a cryptographic key-pair using the device check API. The key resides in the device's "Secure Enclave" and the operation responds with a reference to that public/private key pair with an identifier string (the key ID string is a SHA256 hash of the public key).
A hash of the challenge data along with the key identifier is sent to the Apple App Attest service over the internet. The service responds with the attestation data as a string of bytes.
The attestation data is provided to your server, and the server validates the attestation data.
Subsequence requests to your server are accompanied by assertion data which are generated on the device with the key identifier and the request body.
The assertion data are then validated and the request is processed.

Let's break down how each of these things work. Then iterate on the process to try and take into account HTTP standards for authentication and security practices.

Warning: Check that App Attest is Available

A "step zero" not mentioned above is that you should check your App's platform supports the App Attest service before continuing the process.

let service = DCAppAttestService.shared
if service.isSupported {
    // Perform key generation and attestation.
}
// Continue with server access.

The annoying fact about DCAppAttestService is that it doesn't work on the simulator. 😣

The documentation states it is available on the following platform versions:

iOS	iPadOS	macOS	tvOS	watchOS
14.0+	14.0+	11.0+.	15.0+	9.0+

Generating the Challenge (.NET)

In response to some request from your app, your server responds with a string of random bytes, which are referred to as the "challenge".

In cases of security and cryptography, random is just not just any PRNG, it should be cryptographically random so that the sequence cannot be easily anticipated by an attacker.

In .NET, we can use the RandomNumberGenerator found in the System.Security.Cryptography namespace and we simply call GetBytes(length) on the static instance of the class to get a cryptographically random sequence of bytes at the desired length.

Generating a Public/Private Key Pair and ID (Swift)

The Apple docs give detail on this, you will want to persist the key identifier response in a local cache or storage so it may be used later in the process.

The generated key pair and identifier are unique for each user account on each device running your app. So you only need to store one key identifier in your code.

The basic code for generating the key pair is:

service.generateKey { keyId, error in
    guard error == nil else { /* Handle the error. */ }

    // Cache keyId for subsequent operations.
}

I prefer to use async/await rather than callbacks, so here it is refactored:

public func getKeyId() async throws -> String {
    if let keyId = try _keyId.value {
        return keyId
    }

    return try await withCheckedThrowingContinuation { continuation in
        _service.generateKey { keyId, error in
            if let keyIdValue = keyId {
                do {
                    try self._keyId.set(value: keyIdValue)
                    continuation.resume(returning: keyIdValue)
                }
                catch {
                    continuation.resume(throwing: AppAttestError.GetKey(error))
                }
            }
            else {
                continuation.resume(throwing: AppAttestError.GetKey(error))
            }
        }
    }
}

The above code makes use of an instance of self._keyId to manage the reuse of a generated key pair. The instance is of a type that serves as an interface to the device keychain secret storage, the implementation of that will be shown later.

It also uses AppAttestError, and again, I will share this code later.

Try and get the stored keyId value and return early.
Asynchronously generate the key pair and handle errors with either generation or persisting the key identifier
Capture the key identifier response (or error) with the continuation.

Generate Attestation (Swift)

After retrieving the challenge and obtaining the key identifier we should generate the attestation data. Keep in mind this operation is made against an Apple ran web service; from my experimentation, this service frequently times out or is temporarily unavailable, so make sure to consider this in your design.

When generating the attestation data we need to make use of both the challenge we received earlier and the key identifier.

Apple's instructions for implementing this step are shown under Certify the key pairs as valid.

import CryptoKit

let challenge = <# Data from your server. #>
let hash = Data(SHA256.hash(data: challenge))

service.attestKey(keyId, clientDataHash: hash) { attestation, error in
    guard error == nil else { /* Handle error and return. */ }

    // Send the attestation object to your server for verification.
}

As before, here is a sensible implementation of this function using async.

public func generateAttestation(keyId: String, challenge: Data) async throws -> Data {
    let challengeHash = Data(SHA256.hash(data: challenge))

    return try await withCheckedThrowingContinuation { continuation in
        _service.attestKey(keyId, clientDataHash: challengeHash) { attestation, error in
            if let attestationValue = attestation {
                continuation.resume(returning: attestationValue)
            }
            else if let dcError = error as? DCError, dcError.code == .invalidKey {
                do {
                    try self._keyId.remove()
                    continuation.resume(throwing: AppAttestError.GenerateAttestation(error))
                }
                catch {
                    continuation.resume(throwing: AppAttestError.GenerateAttestation(error))
                }
            }
            else {
                continuation.resume(throwing: AppAttestError.GenerateAttestation(error))
            }
        }
    }
}

The above code handles the case of the "invalid key" App Attest error. In this scenario, we should invalidate the local key identifier cache so that it will get recreated.

Validating Attestation Statement

The steps to validating the attestation statement are outlined here.

This represents the bulk of the protocol implementation, there are lots of steps and lots of concepts to understand. Let's try and break it down to make it digestible.

High-Level Steps

Decode the attestation data
Verify statement certificates
Verify cryptographic nonce
Verify key identifier against statement certificate
Verify app identifier
Verify the signing counter
Verify development or production environment
Verify key identifier against credential identifier
Store attestation data for assertion data verification

... yikes 😅

I don't expect all of that to make sense at this point, so please continue reading...

The Attestation Object Structure

To decode the attestation statement we need to cover:

concepts and structures detailed within the Web Authentication specification
CBOR & COSE encoding
ASN.1 encoding
big/little endian encoding
struct marshalling

... yikes 😅

I think probably the best way to break down this problem is to show the hierarchy of types within the attestation data and then detail their encoding and semantics.

attestation: Represents the CBOR encoded map represented by the attestation data return from the App Attest service.
- fmt: CBOR encoded string that identifies the statement format. For Apple's Device Check App Attest, it is always "apple-appattest".
- attStmt: The attestation "statement", encoded as a CBOR map.
- x5c: CBOR encoded array of byte arrays, each byte array is encoded as an X509 certificate.
  - Index 0: The public certificate of the key pair generated by the app.
  - Index 1: Intermediate signing certificate. The chain is represented by root -> intermediate -> auth cert.
- receipt: CBOR encoded byte array can be sent to the App App Attest service to get information on the risk metric associated with the attestation.
- authData: Or "Authenticator Data" is defined within the web authentication spec. For the most part, data in this structure is fixed width, so we can marshal the bytes directly to a struct (mostly 😅).
- rpidHash: As the name suggests, this is a hash of the RPID, or relying party identifier. Within App Attest, the RP is always your app's "App ID".
- flags: bitflags to describe the auth data; does it include attest data? Is the user verified? Is there extensions on this auth data? Stuff like that...
- signCount: A counter for how many times the signature has signed content. When parsing the attestation statement, this figure is zero.
- attestedCredentialData: Contains the credential data for the corresponding attestation. App Attest uses the key identifier as the credential identifier
  - aaguid: Determines if the app attest environment is development or production.
  - credentialIdLength: A big-endian UInt16 value for the length credentialId.
  - credentialId: The attested credential identifier. For the purposes of app attest, the key identifier and the credential identifier are the same value.
  - credentialPublicKey: COSE key, the encoding of which is a whole thing, but since the apple App Attest protocol does not make use of this field, I won't spend time going into it.

Decoding the Attestation Object

The first level of decoding the attestation object required CBOR decoding. To decode a CBOR encoded object you can pull in a library like Dahomey.Cbor, or write your own. Somewhere in the middle is using what Microsoft provides with System.Formats.Cbor.CborReader. You still need to do a lot of the lifting and write a deserialiser, but the class can help.

To understand CBOR encoding better, take a look at my article here.

Understanding CBOR Encoded Data

Matt Nelson-White — Tue, 24 Jan 2023 11:29:33 +0000

CBOR, or Concise Binary Object Representation, is an efficient way of serializing data objects, similar to what you see in the protobuf standard.

The reason I tried to understand this is because it was used throughout the web authentication security protocol.

Why may it be of interest to you?
Maybe you want to:

Read dense and highly technical articles 🤷‍♀️.
Understand a byte encoding standard which is becoming more relevant for web security.
Write your own serialiser to avoid adding a dependency to some of the existing libraries which do it well.
Amaze your friends and family!

The Encoding Rules

CBOR encoding data is structured as a sequence of CBOR header and CBOR data pairs. The header part determines the format and the length of the data segment.

Table 1 - Header Structure

1 Byte Header		Data
Major Type	Additional Info	Data
3 Bits	5 Bits	n Bytes

All possible 3-bit values of the major type are shown in the table below.

Table 2 - Major Types

Major Type	Semantics
`0x00`	Unsigned Integer
`0x01`	Negative Integer
`0x02`	Byte String
`0x03`	Text String
`0x04`	Array
`0x05`	Map
`0x06`	Tag
`0x07`	Simple/Float

Unsigned Integer (MT 0)

An unsigned integer may have a value which ranges from 0 to 2⁶⁴-1, but the number of bytes used to express the integer are specified in the additional information part of the header.

Table 3 - Integer size

Add. Info.	Semantics
`0x18`	8 bit
`0x19`	16 bit
`0x1A`	32 bit
`0x1B`	64 bit

So that an 8 bit unsigned integer has a header of

(mt) 0b0000_0000 | (add. info.) 0b0001_1000 = (hdr) 0b0001_1000

And an unsigned integer value of 24 including the header would read as 0b0001_1000_0001_1000 or 0x1818.

A cool trick is that numbers 0 to 23 can all be represented as a header byte only. This means that the integer value of 23 can be represented as 0x1817 or just as 0x17 (0b0001_0111).

Negative Integer (MT 1)

A negative integer may have a value which ranges from 2⁶⁴ to -1. Where value = -1 - argument.

Negative integers also use the same additional information as unsigned integers as seen in table 3.

So to represent -500, the header of 0b0011_1001 should be used, which means "negative integer with 16 bits"; and a value of -1 - 500 = 499 (0b0000_0001_1111_0011); altogether 0b0011_1001_0000_0001_1111_0011 or 0x3901F3.

Just as before values of 0 to 23 can be represented just in the header byte, which means that it would represent negative integers of -1 to -24, where -24 is 0x37 (0b0011_0111).

Byte String (MT 2)

Similar to the rules we have established for both unsigned integers and negative integers, we can specify a byte string length just with the header value if the length is from 0 to 23, and for longer strings, follow the additional information codes shown in table 3.

Encoding the byte string 0x01020304 results in 0x4401020304. The header 0x44 or 0b0100_0100, represents major type 2 and a length of 4.

A byte string of 500 octets would have the major type of 0x02 followed by the additional information of 0x19 (16 bits), 0x01F4 to specify the length of 500, then 500 bytes for the value.

Text String (MT 3)

A CBOR text string is always UTF-8 and the number of bytes in the string is given by the length argument formatted in the same way as a byte string.

The UTF-8 string represented by the bytes 0x6C6F6FC9942073E1B4892073E1B489C9A5CA87 has a length of 19. Since the length is less than 23, we can represent the length with only the header byte of 0b0111_0011 or 0x73, encoding the string as 0x736C6F6FC9942073E1B4892073E1B489C9A5CA87.

73                                      # text(19)
   6C6F6FC9942073E1B4892073E1B489C9A5CA87 # "looɔ sᴉ sᴉɥʇ"

Array (MT 4)

Arrays have a length, and as expected the length is represented in the same way as all the other major types described so far. Furthermore, and array is more like a tuple, since it is not constrained to encapsulate a single type.

An array of 2 elements would look like:

0b100 MT4 bits
0b00010 Additional information for length of 2
0b0000_0001 Integer value of 1
0b0001_1001_0000_0001_1111_0100 Integer value of 500

The encoded result is 0x82011901F4.

82         # array(2)
   01      # unsigned(1)
   19 01F4 # unsigned(500)

Map (MT 5)

A map (also known as a dictionary) is similar to an array which is read as a sequence of key/value pairs; if we used the array specified above as a map, it would read the first array element as the first key and the second element as the first value. This means that a valid map type always has an even number of elements.

Since the map's keys are used to lookup the corresponding value, the map should not have any duplicate keys.

Using the example array above, and changing the major type to 5 the encoded result is 0xA1011901F4.

A1         # map(1)
   01      # unsigned(1)
   19 01F4 # unsigned(500)

Tag (MT 6)

A tag operates as an extension point for an extended number of types (see IANA CBOR Tags for full list) where we can specify data structures that represent datetime, big numbers, URLs and much much more. The way it works is that the tag encodes a number which then describes a well known tag data type.

For example, the tag value of 0 corresponds to a RFC3339 datetime.
Representing the RFC3339 datetime "1985-04-12T23:20:50.52Z" we can first start with the encoded string

77                                      # text(23)
   313938352D30342D31325432333A32303A35302E35325A # "1985-04-12T23:20:50.52Z"

and then prefix the encoding with the tag header 0b110 (tag) 0b00000 (0 value = RFC3339 datetime), or 0xC0.

C0                                      # tag(0)
   77                                   # text(23)
      313938352D30342D31325432333A32303A35302E35325A # "1985-04-12T23:20:50.52Z"

The decoder then knows the following string should be interpreted as a RFC3339 datetime.

Simple/Float (MT 7)

A major type 7 is either a floating point number or a simple value depending on the additional information part of the header.

Table 4 - Simple/Float Additional Information

Add. Info.	Semantics
`0x14`	false
`0x15`	true
`0x16`	null
`0x17`	undefined
`0x19`	IEEE 754 Half-Precision Float (16 bits follow)
`0x1A`	IEEE 754 Single-Precision Float (32 bits follow)
`0x1B`	IEEE 754 Double-Precision Float (64 bits follow)
`0x1F`	"break" stop code for indefinite-length items

A value of 3.14159 can be expressed as a 64 bit float as 0xFB400921F9F01B866E.

Indefinite Length Strings, Arrays & Maps

Byte strings, along with text strings, arrays and maps have another way of defining length. They can use the additional information code 0x1F which signifies that the sequence has an "indefinite length". This is used for scenarios where the length is unknown, like in streaming scenarios.

The termination of a indefinite length sequence is the "break" or "stop" code, which is major type 7 with a additional information code of 0x1F, together the header is 0xFF.

Strings

For byte and text strings of an indefinite length, the data arrives in chunks. Each chunk has a specified length. The sequence of chunks are terminated by the break code 0xFF.

The CBOR encoded data 0x5F440102030443010203FF describes an indefinite length byte string with two chunks, respectively of length 4 and 3 bytes.

5F             # header for the indefinite length byte string
   44          # the header for a byte string of length 4
      01020304 # the first chunk of 4 bytes
   43          # the header for a byte string of length 3
      010203   # the second chunk of 3 bytes
   FF          # the indefinite length byte string is terminated with the "break" code

Arrays & Maps

The CBOR encoded data 0x9F00203040506070809FF describes an indefinite length array of unsigned integers.

9F    # header for the indefinite length array
   00 # unsigned(0)
   01 # unsigned(1)
   02 # unsigned(2)
   03 # unsigned(3)
   04 # unsigned(4)
   05 # unsigned(5)
   06 # unsigned(6)
   07 # unsigned(7)
   08 # unsigned(8)
   09 # unsigned(9)
   0A # unsigned(10)
   FF # the indefinite length array is terminated

These arrays can be nested with definite length arrays as well. The CBOR data 0x9F018202039F0405FFFF is an indefinite length array that is comprised of:

an element
a definite length array of 2 elements
an indefinite length array of 3 elements

9F       # array(*)
   01    # unsigned(1)
   82    # array(2)
      02 # unsigned(2)
      03 # unsigned(3)
   9F    # array(*)
      04 # unsigned(4)
      05 # unsigned(5)
      FF # primitive(*)
   FF    # primitive(*)

Final Thoughts

There are some interesting tricks used in the standard to really make the encoding economical. There are pros and cons using CBOR when compared to other standards like protobuf.

With protobuf you need to distribute definition files in order to decode the data, which leads to much more efficiently encoded class structures (map keys are often strings). You can encode your class structures with enums to represent the class properties, and then distribute the enum definitions. So from that point of view, CBOR can be pretty damn close to protobuf but a hell of a lot more readable (once you understand the standard).

If you are interested, I wrote a simple deserialiser in C#. If you would like to know more about the explanation feel free to reach out.

CBOR is also extended to include a way of signing and encrypting CBOR encoded objects, called COSE or CBOR Object Signing & Encryption which is used by web authentication protocols like App-Attest.

Check out CDDL (Concise Data Definition Language) as a way to define your CBOR structures.

How To Manually Verify x509 Certificate Chains in .NET

Matt Nelson-White — Tue, 10 Jan 2023 11:38:58 +0000

I am frequently in a situation where I rely on using certificates to secure my applications, but the methods vary quite a bit. One thing is clear, I prefer to provide root or intermediate certificates for validation purposes, to the runtime by configuration and not using the system certificate store.

The .NET framework has a X509Chain class where a x509 certificate chain can verify a certificate. However, the problem with this API is that it uses the system's root certificate store to validate the certificate. In scenarios where the root certificate is only held by the application and is not present in the system's root store, this API does not give reliable results.

Looking around online there really doesn't appear to be any solution to this other than "use bouncycastle", but for those who don't really want to introduce such a large project dependency to validate a certificate chain then that solution may not be appetising.

X509 Certificate Structure

In order to understand how to validate a certificate chain, we need to understand how a X509 certificate is structured and encoded.

According to RFC 3280 Section 4.1, the certificate is a ASN.1 encoded structure, and at it's base level is comprised of only 3 elements.

Certificate  ::=  SEQUENCE  {
    tbsCertificate       TBSCertificate,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING
}

tbsCertificate: This is the "To Be Signed" certificate structure which is signed by the the signing certificate. The RFC describes this as:

The field contains the names of the subject and issuer, a public key associated with the subject, a validity period, and other associated information.

So pretty much all the certificate extensions and information.

signatureAlgorithm: This is an identifier for the algorithm used to sign the tbsCertificate; this information is used to know which algorithm to validate the certificate signature, using the signing certificate's public key.

signatureValue: This is a sequence of bytes which represents the cryptographic proof that the certificate has in fact been signed by some other signing certificate.

Broadly speaking, to validate the certificate we provide the algorithm identified by the signatureAlgorithm along with the tbsCertificate and the signatureValue and the validation function returns a bool to indicate whether the certificate was signed by the chosen signing certificate.

Decoding the Certificate

The certificate data is ASN.1 encoded; but what is ASN.1 encoding? It is essentially a standard for "defining data structures that can be serialised and deserialised in a cross-platform way" (ASN.1).

The standard includes different standards of encoding rules, such as BER, DER, CER, and many others.

For the purposes of decoding a X509 certificate, we only need knowledge of BER and DER (a restricted subset of BER)

The way BER ASN.1 encoding works is the first set of bytes in the data indicates the tag, which is a ASN.1 term to describe the type of data that is encoded.

The next bytes are the data length, then the data itself. For example:

For example, the bytes 0304FFA0CB01 can be deconstructed to:

tag	length	value
`03`	`04`	`FFA0CB01`

The tag 03 corresponds to the OCTET STRING type. So the deserialiser knows to read 4 bytes into an octet string of FFA0CB01.

Looking at the ASN.1 definition for the certificate we can work out the basic structure.

Certificate  ::=  SEQUENCE  {
    tbsCertificate       TBSCertificate,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING
}

TBSCertificate  ::=  SEQUENCE  {
    version         [0]  EXPLICIT Version DEFAULT v1,
    serialNumber         CertificateSerialNumber,
    signature            AlgorithmIdentifier,
    issuer               Name,
    validity             Validity,
    subject              Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
    subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
    extensions      [3]  EXPLICIT Extensions OPTIONAL
}

AlgorithmIdentifier  ::=  SEQUENCE  {
    algorithm            OBJECT IDENTIFIER,
    parameters           ANY DEFINED BY algorithm OPTIONAL
}

The data is nested inside a SEQUENCE type (tag 0x10)
In order to validate the certificate, we don't need to decode the tbsCertificate, we just need to extract the bytes from the sequence.
The signatureAlgorithm is another sequence from which we want to extract the algorithm OID to know which algorithm to use.
Finally the signatureValue should not even be in a sequence and is just a BIT STRING (tag 0x03).

Fortunately .NET has AsnDecoder which can help with decoding ASN.1 structures.

Decoding the TBS Certificate

Looking at the methods and properties of the X509Certificate2 type, it does not contain any way to extract the TBS Certificate from it, but we can use what we know to decode the certificate using the AsnDecoder.

To decode the TBS Certificate from the X509 Certificate, we can write an extension method.

public static ReadOnlySpan<byte> GetTbsCertificate(
    this X509Certificate2 certificate,
    AsnEncodingRules encodingRules = AsnEncodingRules.BER)
{
    var signedData = certificate.RawDataMemory;
    AsnDecoder.ReadSequence(
        signedData.Span,
        encodingRules,
        out var offset,
        out var length,
        out _
    );

    var certificateSpan = signedData.Span.Slice(offset, length);
    AsnDecoder.ReadSequence(
        certificateSpan,
        encodingRules,
        out var tbsOffset,
        out var tbsLength,
        out _
    );

    // include ASN1 4 byte preamble offset to get WHOLE TBS Cert
    return certificateSpan.Slice(tbsOffset - 4, tbsLength + 4);
}

The method starts by getting the raw data of the certificate from the X509Certificate2 type.
From the ASN.1 definitions shown above we know that the certificate data is within an ASN.1 sequence type, AsnDecoder.ReadSequence is used to find the offset and length of that sequence.
Because we are good people, we use a span to reduce allocations.
Now we can start decoding the elements of the structure, the TBS certificate is the first of the ranks. It can be read as a sequence.
Even though we know the TBS Certificate offset and length, this is not exactly the data we need. After a lot of hair pulling, I discovered the signature is actually based on the data INCLUDING the ASN.1 SEQUENCE preamble. Not including this will give you the wrong data! 😣.

Decoding the Signature Algorithm

In Microsoft's infinite grace, they have already included a property on the X509Certificfate2 type to obtain the signature algorithm.

The SignatureAlgorithm property returns the OID for the algorithm. Microsoft has a table of signature algorithm OIDs and their corresponding algorithms; we can write our code to accommodate the algorithms we want.

If you are writing your own library you probably want to support as many as possible, but for the purposes of the article, we only need to support some common variants. The OIDs are often organised hierarchically by encryption algorithm and hashing algorithm; for example, RSA has a prefix of 1.2.840.113549.1.1. and SHA256, SHA384 and SHA512 OIDs are 1.2.840.113549.1.1.11, 1.2.840.113549.1.1.12 and 1.2.840.113549.1.1.13 respectively.

Decoding the Signature

Unfortunately the X509Certificate2 type does not help us extract the signature data, but knowing what we already know it should be pretty trivial. The only annoyance is that we need to know the length of the TBS certificate and the signature algorithm to get the offset to read the signature.

We can write a separate method to extract the signature, but it needs to read through the other elements.

public static byte[] GetSignature(
    this X509Certificate2 certificate,
    AsnEncodingRules encodingRules = AsnEncodingRules.BER)
{
    var signedData = certificate.RawDataMemory;
    AsnDecoder.ReadSequence(
        signedData.Span,
        encodingRules,
        out var offset,
        out var length,
        out _
    );

    var certificateSpan = signedData.Span.Slice(offset, length);
    AsnDecoder.ReadSequence(
        certificateSpan,
        encodingRules,
        out var tbsOffset,
        out var tbsLength,
        out _
    );

    var offsetSpan = certificateSpan[(tbsOffset + tbsLength)..];
    AsnDecoder.ReadSequence(
        offsetSpan,
        encodingRules,
        out var algOffset,
        out var algLength,
        out _
    );

    return AsnDecoder.ReadBitString(
        offsetSpan[(algOffset + algLength)..],
        encodingRules,
        out _,
        out _
    );
}

Verifying the Certificate Chain

Now that we have extracted all three elements of the X509 certificate necessary to verify signing by a signing certificate. We can write another extension to determine if a target signing certificate (signedBy) has signed a particular certificate (signed).

The overall approach is:

Using the signature algorithm OID determine which encryption algorithm is being used (we will write for RSA and ECDsa) and use that information to know what type of public key to extract from the signedBy certificate.
Using the VerifyData method on the public key, we provide the TBS certificate, the signature data, and the hash algorithm, which is obtained from the signature algorithm OID as well.
We will also need to identify the type of signature padding for RSA, and the DSA signature format for ECDsa. We won't go into determining that from the certificate data, instead we will define them statically.

public static bool IsSignedBy(
    this X509Certificate2 signed,
    X509Certificate2 signer)
{
    var signature = signed.GetSignature();
    var tbs = signed.GetTbsCertificate();
    var alg = signed.SignatureAlgorithm;

    switch (alg)
    {
        case { Value: var value } when value?.StartsWith("1.2.840.113549.1.1.") is true:
            return signer.GetRSAPublicKey()?.VerifyData(
                tbs,
                signature,
                value switch {
                    "1.2.840.113549.1.1.11" => HashAlgorithmName.SHA256,
                    "1.2.840.113549.1.1.12" => HashAlgorithmName.SHA384,
                    "1.2.840.113549.1.1.13" => HashAlgorithmName.SHA512,
                    _ => throw new UnsupportedAlgorithm(alg)
                },
                RSASignaturePadding.Pkcs1
            ) ?? false;
        case { Value: var value } when value?.StartsWith("1.2.840.10045.") is true:
            return signer.GetECDsaPublicKey()?.VerifyData(
                tbs,
                signature,
                value switch {
                    "1.2.840.10045.4.3.2" => HashAlgorithmName.SHA256,
                    "1.2.840.10045.4.3.3" => HashAlgorithmName.SHA384,
                    "1.2.840.10045.4.3.4" => HashAlgorithmName.SHA512,
                    _ => throw new UnsupportedAlgorithm(alg)
                },
                DSASignatureFormat.Rfc3279DerSequence
            ) ?? false;
        default: throw new UnsupportedAlgorithm(alg);
    }
}

The one thing in this code that took WAY too long to work out was that the ECDsa Verify method has an overload for the DSASignatureFormat parameter. I have NO IDEA why it defaults to a non-DER format, but it does, and does not work unless you discover this overload.

The above approach can be expanded and abstracted to support more algorithms, but as is it supports the most common algorithms with very little code.

Other checks, such as comparing the "not before" and "not after" dates on the certificate extensions can be done elsewhere to separate concerns.

Example Usage

if (!myCertificate.IsSignedBy(rootCertificate)
{
    throw new InvalidCertificateException();
}