IoTや制約環境向けCBOR（RFC 8949）バイナリ直列化の仕組み
CBORのデータモデルと短い符号化、プロトコルごとに定める決定的表現、COSEによるセキュリティ構造の役割を解説します。
発行・訂正窓口：infostoa · 編集基準
この記事の個別の執筆者・専門査読者の情報は提供されていません。
CBOR（Concise Binary Object Representation）は、JSONに関連する構造化データをバイナリで表すIETF標準です。小さな整数や短いフィールドは少ないバイトで表現でき、メモリや帯域が限られる機器に役立つ場合があります。ただし、常にJSONより小さくなるわけではなく、CBOR自体が署名や暗号化を行うわけでもありません。RFC 8949は表現形式とデータモデルを、RFC 9052はCBOR上に署名・暗号オブジェクトを構成するCOSEの構造と手順を定めています。
JSONを基礎にしつつ追加の型を持つ
CBORのデータモデルはJSONモデルを拡張したものです。整数、文字列、配列、マップ、真偽値、nullに加えて、通常のJSONには直接対応しないバイト文字列、タグ、より広い数値範囲も表現できます。なじみのある構造を保ちながら、バイナリ転送に適した型を選べます。CBORはJSONの文法をそのまま圧縮したものではなく、二つの形式を変換する際にはJSONで直接表せない値の扱いを決める必要があります。
CBORのデータ項目は、主要型と追加情報を表す初期バイトから始まります。小さな値は短いヘッダーで表せますが、大きな値や文字列には長さ情報が続きます。RFC 8949の例では、整数0は1バイトの00、整数24は18 18で表されます。値に応じて長さが変わることが、簡潔な符号化を支える一つの仕組みです。実際の削減量は値、フィールド名の繰り返し、周辺プロトコルのヘッダー、エンコーダーの選択で変わります。
短い表現が役立つ条件
小さなセンサーメッセージを頻繁に送る場合や、電力・メモリ・通信量が制約される場合、数値・配列・マップの簡潔な符号化が転送量を減らす助けになります。長い文字列キーの代わりに短い整数キーを割り当て、繰り返しの名称を送らない設計もできます。一方、バイナリは人が目で読みづらく、デバッグには専用ツールが必要で、スキーマやキー割当の管理も伴います。運用担当者が手軽に読めることや編集のしやすさが重要なら、JSONのほうが適することもあります。
削減を決めつけず、実際のメッセージで測定しましょう。同じデータモデルでも、キーの長さ、文字列の反復、数値範囲、メッセージの区切り方で結果が変わります。比較には暗号タグや転送フレーミングなどの追加分も含めます。一つの小さな例だけから本番通信全体のコスト削減を結論づけず、実機と採用予定ライブラリで代表例と最大ケースを試してください。
決定的な符号化はプロトコルが選ぶ
同じ意味のCBORデータでも、異なるバイト列で符号化される場合があります。マップの順序や数値幅が違えば、同じ値に復号できても元のバイト列は異なります。RFC 8949は、プロトコルが決定的形式を独自に定義し、受信側にその形式の確認を求めることもできると説明します。全ての用途に共通する唯一の正準バイト列がCBORだけで自動的に決まるわけではありません。
ハッシュ、署名、キャッシュキーが符号化バイトに依存するなら、送信側と受信側が同じ規則を明記して使う必要があります。マップキーの順序、整数や浮動小数点の表現、長さ表現、タグの扱いなどを合意します。ライブラリの既定出力を共通標準とみなすと、独立した実装が同じデータを異なるバイト列にし、署名検証やキャッシュ照合に失敗する可能性があります。決定性は偶然のエンコーダー設定ではなく、相互運用要件として定義します。
COSEがセキュリティオブジェクトの構造を加える
COSEは、CBORベースのオブジェクトに署名、メッセージ認証、暗号化を適用する構造と手順を定めます。RFC 9052のCOSE_Signは複数署名を含められ、COSE_Sign1は署名者一人の形式です。署名計算ではどちらの構造かも区別されるため、形式を変換すると検証に失敗します。署名オブジェクトには保護ヘッダー、非保護ヘッダー、ペイロード、署名データが定義された構造で入ります。
専門家の設計観点では、「CBORなら安全か」ではなく、どのバイト列とヘッダーを署名対象にするか、別送する内容をどう同一に保つかを問います。RFC 9052は、保護ヘッダー内のアルゴリズム情報を認証する必要性や、分離ペイロードを変更せず運ぶ責任がアプリケーションにあることを扱います。COSEを選ぶだけで鍵管理、アルゴリズム方針、再送防止、アプリケーション権限の検証まで自動的に解決するわけではありません。
導入前に確認する実装条件
まずJSONとCBORの変換で保持すべき型を定義します。バイト文字列、大きな整数、タグ、浮動小数点、マップキーの制約、スキーマ変更への対応を確認します。通常のメッセージだけでなく、最大長、不正入力、未知のタグ、重複キー、途中で切れたデータもテストします。RFC 8949は、正しく構成されていない入力をデコーダーが有効なデータとして返さないことを求めています。
決定的符号化が必要なら、採用ルールを文書化し、異なる実装が同じバイト列を生成するか試験します。セキュリティが必要ならCOSE構造とアルゴリズムを別に検討し、署名対象のペイロードが正確に保持されることを確かめます。最後に実機・ネットワークでサイズ、処理時間、メモリ、エラー復旧、運用時の観測性をJSONと比較します。その結果から、スキーマとツールの追加負担に見合うか判断できます。
CBORの価値は単にバイナリであることでは決まりません。制約環境では簡潔な表現と拡張型が有用ですが、決定性、スキーマ、安全なメッセージ処理への責任も伴います。RFC 8949の直列化規則とRFC 9052のCOSE構造を区別すれば、サイズと相互運用性を合わせて評価できます。