ASN.1 Parser and Encoder including a DSL to generate ASN.1 structures
Parse, create, explore certificates, public keys, CSRs, and arbitrary ASN.1 structures on all supported platforms
Powerful, expressive, type-safe ASN.1 DSL on all KMP targets
This last bit means that you can share ASN.1-related logic across platforms.
The very first bit means that you can create and verify signatures on the JVM, Android and on iOS, using platform-native
crypto hardware.
Do check out the full manual with examples and API docs here!
This README provides just an overview.
The full manual is more comprehensive, has separate sections for each module, provides examples, and a full API documentation.
Using it in your Projects
This library was built for Kotlin Multiplatform. Currently, it targets
the JVM, Android and iOS.
It consists of four modules, each of which is published on maven central:
Name
Info
Indispensable ASN.1 module containing the most sophisticated KMP ASN.1 engine in the known universe. kotlinx-* dependencies aside, it only depends only on KmmResult for extra-smooth iOS interop.
Indispensable base module containing the cryptographic data structures, algorithm identifiers, X.509 certificate, …. Depends on the ASN.1 engine.
Indispensable Josef JOSE add-on module containing JWS/E/T-specific data structures and extensions to convert from/to types contained in the base module. Includes all required kotlinx-serialization magic to allow for spec-compliant de-/serialization.
Indispensable Cosef COSE add-on module containing all COSE/CWT-specific data structures and extensions to convert from/to types contained in the base module. Includes all required kotlinx-serialization magic to allow for spec-compliant de-/serialization.
Supreme KMP crypto provider implementing hardware-backed signature creation and verification across mobile platforms (Android KeyStore / iOS Secure Enclave) and JCA compatibility (on the JVM).
This separation keeps dependencies to a minimum, i.e. it enables including only JOSE-related functionality, if COSE is irrelevant.
More importantly, in a JVM, iOS, or Android-only project, it allows for processing cryptographic material without imposing the inclusion of a crypto provider.
Simply declare the desired dependency to get going:
Looking for a KMP cryptography framework, you have undoubtedly come across
cryptography-kotlin. So have we and it is a powerful
library, supporting more platforms and more cryptographic operations than Signum Supreme.
This begs the question: Why implement another, incompatible
cryptography framework from scratch? The short answer is: Signum and cryptography-kotlin pursue different goals and priorities.
cryptography-kotlin strives for covering a wide range of targets and a broad range of operations based on a flexible provider architecture.
Signum, on the other hand, focuses on tight platform integration (including hardware-backed crypto and attestation!),
and comprehensive ASN.1, JOSE, and COSE support.
More…
Signum was born from the need to have cryptographic data structures available across platforms, such as public keys, signatures,
certificates, CSRs, as well as COSE and JOSE data. Hence, we needed a fully-featured ASN.1 engine and mappings from
X.509 to COSE and JOSE datatypes. We required comprehensive ASN.1 introspection and builder capabilities across platforms.
Most notably, Apple has been notoriously lacking anything even remotely usable
and SwiftASN1 was out of the question for a couple of reasons.
Most notably, it did not exist when we started work on Signum. Hence, there was neither ASN.1 parser, nor encoder on Apple platforms
that was actually usable. In effect: there was no KMP ASN.1 codec in sight, much less a type-safe, user-friendly one.
As it stands now, our ASN.1 engine can handle almost anything you throw at it, in some areas even exceeding Bouncy Castle!
cryptography-kotlin only added basic ASN.1 capabilities over a year after Signum’s development started.
We are also unaware of any other library offering comprehensive JOSE and COSE data structures based on kotlinx-serialization.
Hence, we implemented those ourselves, with first-class interop to our generic cryptographic data structures.
We also support platform-native interop meaning that you can easily convert a Json Web Key to a JCA key or even a SecKeyRef on iOS.
Having actual implementations of cryptographic operations available was only second on our list of priorities. From the
get-go, it was clear that we wanted the tightest possible platform integration on Android and iOS, including hardware-backed
storage of key material and in-hardware execution of cryptographic operations whenever possible.
We also needed platform-native attestation capabilities (and so will you sooner or later if you are doing anything
mission-critical on mobile targets!).
While this approach does limit the number of available cryptographic operations, it also means that all cryptographic operations
involving secrets (e.g. private keys) provide the same security guarantees as platform-native implementations do —
because they are the same under the hood. Most notably: hardware-backed private keys
never even leave the hardware crypto modules!
This tight integration and our focus on mobile comes at the cost of the Supreme KMP crypto provider only supporting JVM,
Android, and iOS.
cryptography-kotlin, on the other hand, allows you to perform a wider range of cryptographic functions an all KMP targets,
Most prominently, it already supports RSA encryption, key stretching, and key derivation, which Signum currently lacks.
On the other hand, cryptography-kotlin currently offers neither hardware-backed crypto, nor attestation capabilities.
The following table provides a detailed comparison between Signum and cryptography-kotlin.
Signum
cryptography-kotlin
Digital Signatures
✔ (ECDSA, RSA)
✔ (ECDSA, RSA)
Symmetric Encryption
✔ (AES + ChaChaPoly)
✔ (AES)
Asymmetric Encryption
✔ (RSA)
✔ (RSA)
Digest
✔ (SHA-1, SHA-2)
✔ (MD5, SHA-1, SHA-2)
MAC
✔ (HMAC)
✔ (HMAC)
Key Agreement
✔ (ECDH)
✔ (ECDH)
KDF/PRF/KSF
✔ (PBKDF2, HKDF, scrypt)
✔ (PBKDF2, HKDF)
Hardware-Backed Crypto
✔
✗
Attestation
✔
✗
Fully-Featured ASN.1 Engine
✔
✗
COSE
✔
✗
JOSE
✔
✗
Provider Targets
JVM, Android, iOS
All KMP-supported targets
Supreme Demo Reel
The Supreme KMP crypto provider works differently from JCA. Configuration is type-safe, more expressive and more concise,
meaning you’ll end up with less code. Nothing throws! Do not discard the results returned from any operation!
Signature Creation
To create a signature, obtain a Signer instance.
You can do this using Signer.Ephemeral to create a signer for a throwaway keypair:
val signer = Signer.Ephemeral {}.getOrThrow()
val plaintext = "You have this.".encodeToByteArray()
val signature = signer.sign(plaintext).signature
println("Signed using ${signer.signatureAlgorithm}: $signature")
If you want to create multiple signatures using the same ephemeral key, you can obtain an EphemeralKey instance, then create signers from it:
The instances can be configured using the configuration DSL.
Any unspecified parameters use sensible, secure defaults.
Platform Signers
On Android and iOS, signers using the systems’ secure key storage can be retrieved.
To do this, use PlatformSigningProvider (in common code), or interact with AndroidKeystoreProvider/IosKeychainProvider (in platform-specific code).
New keys can be created using createSigningKey(alias: String) { /* configuration */ },
and signers for existing keys can be retrieved using getSignerForKey(alias: String) { /* configuration */ }.
For example, creating an elliptic-curve key over P256, stored in secure hardware, and with key attestation using a random challenge provided by your server, might be done like this:
val serverChallenge: ByteArray = TODO("This was unpredictably chosen by your server.")
PlatformSigningProvider.createSigningKey(alias = "Swordfish") {
ec {
// you don't even need to specify the curve (P256 is the default) but we'll do it for demonstration purposes
curve = ECCurve.SECP_256_R_1
// you could specify the supported digests explicitly - if you do not, the curve's native digest (for P256, this is SHA256) is supported
}
// see https://a-sit-plus.github.io/signum/supreme/at.asitplus.signum.supreme.sign/-platform-signing-key-configuration-base/-secure-hardware-configuration/index.html
hardware {
// you could use PREFERRED if you want the operation to succeed (without hardware backing) on devices that do not support it
backing = REQUIRED
attestation { challenge = serverChallenge }
protection {
timeout = 5.seconds
factors {
biometry = true
deviceLock = false
}
}
}
}
If this operation succeeds, it returns a Signer. The same Signer could later be retrieved using PlatformSigningProvider.getSignerForKey(alias: String).
When you use this Signer to sign data, the user would be prompted to authorize the signature using an enrolled fingerprint, because that’s what you specified when creating the key.
You can configure the authentication prompt:
val plaintext = "A message".encodeToByteArray()
val signature = signer.sign(plaintext) {
unlockPrompt {
message = "Signing a message to Bobby"
}
}.signature
… but you cannot change the fact that you configured this key to need biometry. Consider this when creating your keys.
On the JVM, no native secure hardware storage is available.
File-based keystores can be accessed using JKSProvider { file { /* ... */ } }.
Other keystores can be accessed using JKSProvider { withBackingObject{ /* ... */ } } or JksProvider { customAccessor{ /* ... */ } }.
For more details, please refer to the provider’s configuration options.
Key Attestation
The Android KeyStore offers key attestation certificates for hardware-backed keys.
These certificates are exposed by the signer’s .attestation property.
For iOS, Apple does not provide this capability.
We instead piggy-back onto iOS App Attestation to provide a home-brew “key attestation” scheme.
The guarantees are different: you are trusting the OS, not the actual secure hardware; and you are trusting that our library properly interfaces with the OS.
Attestation types are serializable for transfer, and correspond to those in Indispensable’s attestation module.
Signature Verification
To verify a signature, obtain a Verifier instance using verifierFor(k: PublicKey), either directly on a SignatureAlgorithm, or on one of the specialized algorithms (X509SignatureAlgorithm, CoseAlgorithm, …).
A variety of constants, resembling the well-known JCA names, are also available in SignatureAlgorithm’s companion.
As an example, here’s how to verify a basic signature using a public key:
val publicKey: CryptoPublicKey.EC = TODO("You have this and trust it.")
val plaintext = "You want to trust this.".encodeToByteArray()
val signature: CryptoSignature = TODO("This was sent alongside the plaintext.")
val verifier = SignatureAlgorithm.ECDSAwithSHA256.verifierFor(publicKey).getOrThrow()
val isValid = verifier.verify(plaintext, signature).isSuccess
println("Looks good? $isValid")
Or here’s how to validate a X.509 certificate:
val rootCert: X509Certificate = TODO("You have this and trust it.")
val untrustedCert: X509Certificate = TODO("You want to verify that this is trustworthy.")
val verifier = untrustedCert.signatureAlgorithm.verifierFor(rootCert.publicKey).getOrThrow()
val plaintext = untrustedCert.tbsCertificate.encodeToDer()
val signature = untrustedCert.signature
val isValid = verifier.verify(plaintext, signature).isSuccess
println("Certificate looks trustworthy: $isValid")
Platform Verifiers
Not every platform supports every algorithm parameter. For example, iOS does not support raw ECDSA verification (of pre-hashed data) for curve P-521.
If you use .verifierFor, and this happens, the library will transparently substitute a pure-Kotlin implementation.
If this is not desired, you can specifically enforce a platform verifier by using .platformVerifierFor.
That way, the library will only ever act as a proxy to platform APIs (JCA, CryptoKit, etc.), and will not use its own implementations.
You can also further configure the verifier, for example to specify the provider to use on the JVM.
To do this, pass a DSL configuration lambda to verifierFor/platformVerifierFor.
val publicKey: CryptoPublicKey.EC = TODO("You have this.")
val plaintext: ByteArray = TODO("This is the message.")
val signature: CryptoSignature.EC = TODO("And this is the signature.")
val verifier = SignatureAlgorithm.ECDSAwithSHA512
.platformVerifierFor(publicKey) { provider = "BC"} /* specify BouncyCastle */
.getOrThrow()
val isValid = verifier.verify(plaintext, signature).isSuccess
println("Is it trustworthy? $isValid")
Symmetric Encryption
We currently support ChaCha20-Poly1503, AES-CBC, AES-GCM, AES-KW, AES-ECB, and a very flexible flavour of AES-CBC-HMAC.
Every symmetric operation is rooted in an algorithm, since the algorithm defines characteristics, such as nonce requirement,
authentication capabilities, etc. Hence, you need to know the algorithm.
Baseline Usage
Once you know decided on an encryption algorithm, encryption itself is straight-forward:
val secret = "Top Secret".encodeToByteArray()
val secretKey = SymmetricEncryptionAlgorithm.ChaCha20Poly1305.randomKey()
val encrypted = secretKey.encrypt(secret).getOrThrow(/*handle error*/)
encrypted.decrypt(secretKey).getOrThrow(/*handle error*/) shouldBe secret
Encrypted data is always structured and the individual components are easily accessible:
val nonce = encrypted.nonce
val ciphertext = encrypted.encryptedData
val authTag = encrypted.authTag
val keyBytes = secretKey.secretKey.getOrThrow() /*for algorithms with a dedicated MAC key, there's encryptionKey and macKey*/
Decrypting data received from external sources is also straight-forward:
Supreme supports AES-CBC with customizable HMAC to provide AEAD.
This is supported across all Supreme targets and works as follows:
val payload = "More matter, with less art!".encodeToByteArray()
//define algorithm parameters
val algorithm = SymmetricEncryptionAlgorithm.AES_192.CBC.HMAC.SHA_512
//with a custom HMAC input calculation function
.Custom(32.bytes) { ciphertext, iv, aad -> //A shorter version of RFC 7518
aad + iv + ciphertext + aad.size.encodeTo4Bytes()
}
//any size is fine, really. omitting the override generates a mac key of the same size as the encryption key
val key = algorithm.randomKey(macKeyLength = 32.bit)
val aad = Clock.System.now().toString().encodeToByteArray()
val sealedBox = key.encrypt(
payload,
authenticatedData = aad,
).getOrThrow(/*handle error*/)
//because everything is structured, decryption is simple
val recovered = sealedBox.decrypt(key, aad).getOrThrow(/*handle error*/)
recovered shouldBe payload //success!
//we can also manually construct the sealed box, if we know the algorithm:
val reconstructed = algorithm.sealedBox.withNonce(sealedBox.nonce).from(
encryptedData = sealedBox.encryptedData, /*Could also access authenticatedCipherText*/
authTag = sealedBox.authTag,
).getOrThrow()
val manuallyRecovered = reconstructed.decrypt(
key,
authenticatedData = aad,
).getOrThrow(/*handle error*/)
manuallyRecovered shouldBe payload //great success!
//if we just know algorithm and key bytes, we can also construct a symmetric key
reconstructed.decrypt(
algorithm.keyFrom(key.encryptionKey.getOrThrow(), key.macKey.getOrThrow()).getOrThrow(/*handle error*/),
aad
).getOrThrow(/*handle error*/) shouldBe payload //greatest success!
ASN.1 Demo Reel
Classes like CryptoPublicKey, X509Certificate, Pkcs10CertificationRequest, etc. all
implement Asn1Encodable and their respective companions implement Asn1Decodable.
Which means that you can do things like parsing and examining certificates, creating CSRs, or transferring key
material.
Certificate Parsing
val cert = X509Certificate.decodeFromDer(certBytes)
when (val pk = cert.publicKey) {
is CryptoPublicKey.EC -> println(
"Certificate with serial no. ${
cert.tbsCertificate.serialNumber
} contains an EC public key using curve ${pk.curve}"
)
is CryptoPublicKey.RSA -> println(
"Certificate with serial no. ${
cert.tbsCertificate.serialNumber
} contains a ${pk.bits.number} bit RSA public key"
)
}
println("The full certificate is:\n${Json { prettyPrint = true }.encodeToString(cert)}")
println("Re-encoding it produces the same bytes? ${cert.encodeToDer() contentEquals certBytes}")
Which produces the following output:
Certificate with serial no. 19821EDCA68C59CF contains an EC public key using curve SECP_256_R_1
The magic shown above is based on a from-scratch 100% KMP implementation of an ASN.1 encoder and parser.
To parse any DER-encoded ASN.1 structure, call either:
Asn1Element.parse(), which will consume all bytes and return the first parsed ASN.1 element.
This method throws if parsing errors occur or any trailing bytes are left after parsing the first element.
Asn1Element.parseFirst(), which will try to parse a single toplevel ASN.1 element.
Any remaining bytes can still be consumed from the iterator, as it will only be advanced to right after the first parsed element.
Asn1Element.parseAll(), wich consumes all bytes, parses all toplevel ASN.1 elements, and returns them as list.
Throws on any parsing error.
Asn1Elements can encoded by accessing the lazily evaluated .derEncoded property.
Even for parsed elements, this is a true re-encoding. The original bytes are discarded after decoding.
Note that decoding operations will throw exceptions if invalid data is provided!
A parsed Asn1Element can either be a primitive (whose tag and value can be read) or a structure (like a set or
sequence) whose child nodes can be processed as desired. Subclasses of Asn1Element reflect this:
Asn1Primitive
Asn1BitString (for convenience)
Asn1PrimitiveOctetString (for convenience)
Asn1Structure
Asn1Sequence and Asn1SequenceOf
Asn1Set and Asn1SetOf (sorting children by default)
Asn1EncapsulatingOctetString (tagged as OCTET STRING, containing a valid ASN.1 structure or primitive)
Asn1ExplicitlyTagged (user-specified tag + CONTEXT_SPECIFIC + CONSTRUCTED)
Asn1CustomStructure (any other CONSTRUCTED tag not fitting the above options. CONSTRUCTED bit may be overridden)
Convenience wrappers exist, to cast to any subtype (e.g. .asSequence()). These shorthand functions throw an Asn1Exception
if a cast is not possible.
Any complex data structure (such as CSR, public key, certificate, …) implements Asn1Encodable, which means you can:
encapsulate it into an ASN.1 Tree by calling .encodeToTlv()
directly get a DER-encoded byte array through the .encodetoDer() function
A tandem of helper functions is available for primitives (numbers, booleans, string, bigints):
encodeToAsn1Primitive to produce an Asn1Primitive that can directly be DER-encoded
encodeToAsn1ContentBytes to produce the content bytes of a TLV primitive (the V in TLV)
Variations of these exist for Instant and ByteArray.
Check out Asn1Encoding.kt for a full
list of helper functions.
Decoding Values
Various helper functions exist to facilitate decoding the values contained in Asn1Primitives, such as readInt(),
for example. To also support decoding more complex structures, the companion objects of complex classes (such as certificates, CSRs, …)
implement Asn1Decodable, which allows for:
directly parsing DER-encoded byte arrays by calling .decodeFromDer(bytes) and .decodeFromDerHexString
processing an Asn1Element by calling .decodefromTlv(src)
Both encoding and decoding functions come in two safe (i.e. non-throwing) variants:
Check out Asn1Decoding.kt for a full
list of helper functions.
ASN1 DSL for Creating ASN.1 Structures
While it is perfectly possible to manually construct a hierarchy of Asn1Element objects, we provide a more convenient
DSL, which returns an Asn1Structure:
In accordance with DER-Encoding, this produces the following ASN.1 structure:
Application 1337 (9 elem)
[1] (1 elem)
BOOLEAN false
SET (1 elem)
SEQUENCE (2 elem)
SET (2 elem)
PrintableString World
PrintableString Hello
SET (3 elem)
UTF8String !!!
PrintableString World
PrintableString Hello
NULL
OBJECT IDENTIFIER 1.2.603.624.97
Private 51966 (3 byte) Foo
PrintableString Bar
[94] (3 byte) 02012A
SET (4 elem)
BOOLEAN false
BOOLEAN true
INTEGER 3
INTEGER (36 bit) -65789876543
SEQUENCE (3 elem)
NULL
NumericString 12345
UTCTime 2024-09-16 11:53:51 UTC
Limitations
Only DER encoding and parsing of ASN.1 structures is supported
Higher-level abstractions (such as X509Certificate) are too lenient in some aspects and
too strict in others.
For example: DSA-signed certificates will not parse to an instance of X509Certificate.
At the same time, certificates containing the same extension multiple times will work fine, even though they violate
the spec.
This is irrelevant in practice, since platform-specific code will perform the actual cryptographic operations on these
data structures and complain anyway, if something is off.
No OCSP and CRL Checks (though it is perfectly possible to parse this data from a certificate and implement the checks)
Number of supported Algorithms is limited to the usual suspects (sorry, no Bernstein curves )-:)
Contributing
External contributions are greatly appreciated! Be sure to observe the contribution guidelines (see CONTRIBUTING.md).
In particular, external contributions to this project are subject to the A-SIT Plus Contributor License Agreement (see also CONTRIBUTING.md).
The Apache License does not apply to the logos, (including the A-SIT logo) and the project/module name(s), as these are the sole property of
A-SIT/A-SIT Plus GmbH and may not be used in derivative works without explicit permission!
评论