CBOR et ASN.1 en Swift : Guide complet de la sérialisation binaire
Introduction
Quand on parle de sérialisation de données, JSON domine largement l'écosystème web et mobile. Pourtant, dans des domaines critiques comme l'IoT, l'authentification forte (WebAuthn/FIDO2), les certificats numériques ou l'identité mobile (ISO 18013-5), deux formats binaires règnent en maîtres : CBOR (Concise Binary Object Representation) et ASN.1 (Abstract Syntax Notation One).
Cet article vous guide à travers ces deux standards essentiels pour tout développeur Swift travaillant sur des projets sécurisés. Vous découvrirez leur structure, leurs différences, et surtout comment les implémenter efficacement avec les outils disponibles en 2026.
🎯 Qu'est-ce que CBOR ?
CBOR (Concise Binary Object Representation), défini dans la RFC 8949, est un format de sérialisation binaire conçu pour être compact, rapide à parser, et extensible sans négociation de version.
Objectifs de conception
CBOR a été créé avec des objectifs précis qui le distinguent des autres formats :
Compacité du code : Un encodeur/décodeur CBOR peut être implémenté en quelques centaines de lignes de code, idéal pour les microcontrôleurs. Compacité des messages : Les données encodées sont significativement plus petites qu'en JSON. Auto-description : Contrairement à Protocol Buffers, aucun schéma n'est requis pour décoder les données. Extensibilité : Le système de tags permet d'ajouter des types sémantiques sans casser la compatibilité.
Cas d'usage principaux
CBOR est devenu le format de référence dans plusieurs domaines critiques :
IoT et systèmes embarqués : CoAP (Constrained Application Protocol) utilise CBOR comme format de payload par défaut. WebAuthn et FIDO2 : Les attestations et assertions des clés de sécurité sont encodées en CBOR. COSE (CBOR Object Signing and Encryption) : Standard cryptographique défini dans les RFC 9052 et RFC 9053. Mobile Driver's License (mDL) : La norme ISO 18013-5 utilise CBOR pour structurer les documents d'identité numériques.
🔢 Structure CBOR : les 8 types majeurs
CBOR organise ses données en 8 types majeurs, identifiés par les 3 bits de poids fort du premier octet :
| Type | Nom | Description |
|---|---|---|
0 | Unsigned Integer | Entier positif (0 à 2⁶⁴-1) |
1 | Negative Integer | Entier négatif (-1 à -2⁶⁴) |
2 | Byte String | Données binaires brutes |
3 | Text String | Chaîne UTF-8 |
4 | Array | Tableau ordonné |
5 | Map | Dictionnaire clé/valeur |
6 | Tag | Métadonnée sémantique |
7 | Simple/Float | Booléens, null, flottants |
Encodage à longueur variable
CBOR utilise un encodage intelligent où les petites valeurs occupent moins d'octets :
Tags sémantiques
Les tags (type majeur 6) ajoutent du contexte aux données. Quelques tags courants :
| Tag | Signification |
|---|---|
0 | Date/heure ISO 8601 |
1 | Timestamp Unix |
2 | Bignum positif |
3 | Bignum négatif |
24 | Données CBOR encapsulées |
55799 | Self-describing CBOR |
📊 Comparaison des formats de sérialisation
| Critère | JSON | CBOR | MessagePack | Protocol Buffers |
|---|---|---|---|---|
Format | Texte | Binaire | Binaire | Binaire |
Schéma requis | Non | Non | Non | Oui |
Taille typique | 100% | 50-70% | 50-70% | 40-60% |
Parsing | Lent | Rapide | Rapide | Très rapide |
Types binaires | Base64 | Natif | Natif | Natif |
Extensibilité | Limitée | Tags | Types | Versions |
Adoption iOS | Natif | Libs tierces | Libs tierces | Libs tierces |
🛠️ État de l'écosystème Swift
Apple ne fournit pas de framework natif pour CBOR. Deux librairies open-source dominent l'écosystème :
SwiftCBOR
SwiftCBOR offre une API bas niveau avec manipulation directe des types CBOR.
Points forts : Léger, pas de dépendances, contrôle total sur l'encodage.
Points faibles : Pas d'intégration Codable native, API verbeuse pour les cas complexes.
PotentCodables
PotentCodables fournit une suite complète d'encodeurs/décodeurs (CBOR, ASN.1, YAML, JSON) avec intégration Codable.
Points forts : Intégration Codable, support ASN.1/DER, API cohérente.
Points faibles : Plus lourd, dépendances transitives.
🚀 Implémentation pratique
Installation via Swift Package Manager
Encodage et décodage basiques avec SwiftCBOR
Intégration Codable avec PotentCodables
Types custom avec clés numériques (style ISO 18013-5)
Pour les protocoles comme mDL qui utilisent des clés numériques plutôt que des strings :
🔐 COSE : Signatures et chiffrement CBOR
Structure COSE_Sign1
La structure la plus courante pour les signatures à un seul signataire :
Implémentation COSE avec CryptoKit
📜 ASN.1 : le grand-père de la sérialisation binaire
Avant CBOR, il y avait ASN.1 (Abstract Syntax Notation One). Ce standard des années 80 reste omniprésent dans la cryptographie : certificats X.509, clés PKCS#8, signatures CMS. Comprendre ASN.1 est indispensable pour qui travaille avec CryptoKit et les formats d'échange de clés.
Qu'est-ce que ASN.1 ?
ASN.1 est un langage de description de données, pas un format d'encodage en soi. Il définit la structure, puis des règles d'encodage la transforment en bytes :
BER (Basic Encoding Rules) : encodage flexible, plusieurs représentations possibles pour la même donnée. DER (Distinguished Encoding Rules) : sous-ensemble de BER, déterministe — une seule représentation par donnée. C'est DER qui est utilisé pour les certificats et signatures. PER, XER, JER : autres encodages (compacté, XML, JSON) moins courants.
CBOR vs ASN.1 : quand utiliser quoi ?
| Critère | CBOR | ASN.1/DER |
|---|---|---|
Époque | 2013 | 1984 |
Complexité | Simple | Complexe |
Schéma requis | Non | Oui (implicite) |
Usage principal | IoT, WebAuthn, mDL | Certificats, PKI, CMS |
Parsing | Facile | Difficile |
Écosystème Swift | Limité | Très limité |
En pratique : utilisez CBOR pour vos nouveaux protocoles, mais vous devrez manipuler ASN.1 dès que vous touchez aux certificats ou à l'export de clés.
Structure TLV (Tag-Length-Value)
ASN.1/DER utilise une structure TLV similaire à CBOR mais plus verbeuse :
Les tags identifient le type :
| Tag | Type | Description |
|---|---|---|
0x02 | INTEGER | Entier signé |
0x03 | BIT STRING | Chaîne de bits |
0x04 | OCTET STRING | Données binaires |
0x05 | NULL | Valeur nulle |
0x06 | OBJECT IDENTIFIER | OID (identifiant d'algorithme) |
0x0C | UTF8String | Chaîne UTF-8 |
0x13 | PrintableString | Chaîne ASCII restreinte |
0x17 | UTCTime | Date/heure |
0x30 | SEQUENCE | Structure ordonnée |
0x31 | SET | Ensemble non ordonné |
Implémentation ASN.1 avec PotentCodables
PotentCodables offre un support ASN.1 complet via le module PotentASN1. L'encodage et le décodage nécessitent la définition d'un schéma qui décrit la structure ASN.1 attendue :
Encodage d'une structure ASN.1 custom
Créons une structure pour encapsuler une signature avec ses métadonnées :
Convertir entre CBOR et ASN.1
Parfois, vous devez convertir des données entre les deux formats — par exemple, pour intégrer des clés CBOR (COSE_Key) avec des certificats X.509 :
⚡ Performance et bonnes pratiques
Benchmarks typiques
Dans un contexte iOS, voici les ordres de grandeur observés :
| Opération | JSON | CBOR | Gain |
|---|---|---|---|
Encodage 1000 objets | 45ms | 28ms | 37% |
Décodage 1000 objets | 52ms | 31ms | 40% |
Taille payload | 100KB | 62KB | 38% |
Quand utiliser CBOR ?
Recommandé :
- Communication IoT/embarqué (CoAP, LwM2M)
- Protocoles d'authentification (WebAuthn, FIDO2)
- Documents d'identité numérique (mDL, EUDI Wallet)
- Échange de données binaires intensif
- Environnements contraints en bande passante
Éviter :
- APIs REST classiques (JSON natif plus simple)
- Debugging fréquent (CBOR moins lisible)
- Interopérabilité maximale requise (JSON plus universel)
Quand utiliser ASN.1 ?
Recommandé :
- Manipulation de certificats X.509
- Export/import de clés cryptographiques
- Intégration avec PKI existante
- Protocoles legacy (LDAP, SNMP, etc.)
Éviter :
- Nouveaux protocoles (préférer CBOR)
- APIs modernes (préférer JSON ou CBOR)
Debugging CBOR : notation diagnostique
CBOR définit une notation diagnostique pour le debugging, similaire à JSON mais plus explicite :
Tests unitaires avec Swift Testing
🔮 Perspectives : Identity Document Services
CBOR est au cœur de la révolution de l'identité numérique. La norme ISO 18013-5 définit le Mobile Driver's License (mDL), et le futur règlement EUDI (European Digital Identity) s'appuie sur ces mêmes fondations.
Dans un prochain article, nous explorerons en détail les Identity Document Services introduits dans iOS 26, et comment Apple intègre ces standards pour permettre la vérification d'identité directement depuis vos applications.