ブルートゥース®メッシュ証明書ベースのプロビジョニング 技術概要
ブルートゥース®メッシュ証明書ベースのプロビジョニング
技術概要
| リリース： | 1.0.0 |
| 文書バージョン： | 1.0 |
| 最終更新日： | 2023年9月19日 |
| 著者： |
マーティン・ウーリー、BluetoothSIG |
|
Version |
Date |
Author |
Changes |
|
1.0.0 |
September 19, 2023 |
Martin Woolley, Bluetooth SIG |
Initial version |
|
注 Bluetooth Mesh Profile Specificationは名称が変更され、Bluetooth Meshと呼ばれるようになりました。 プロトコル仕様と呼ばれるようになりました。本書および関連論文では、バージョン1.1仕様に言及する場合はこの名称を使用しますが、バージョン1.0仕様については引き続きBluetooth Mesh プロファイル仕様と呼びます。 |
1.背景
Bluetooth Mesh Certificate-based Provisioningは、ブルートゥース® Meshプロトコル仕様のバージョン1.1で導入されました。Bluetooth Mesh Certificate-based Provisioning の機能と利点を十分に理解するには、Bluetooth Mesh バージョン 1.0 のいくつかの側面を理解する必要があります。このセクションでは、Bluetooth Mesh Certificate ベースのプロビジョニングの検討に役立つ背景と背景について説明します。
1.1 プロビジョニング
プロビジョニングとは、デバイスがBluetooth Meshネットワークの一部になるための手順です。プロビジョニングは、ネットワークの試運転や新しいデバイスの追加時にユーザーによって実行されます。プロビジョニングは多忙な職場環境で行われることが多く、デバイスが物理的に設置された後に行われるのが一般的です。
1.2 デバイスの識別とクレデンシャル
プロビジョニングされていないデバイスは、一意のDevice UUIDで自身を識別する。また、工場で割り当てられた一意のプロビジョニング・コードや、静的な公開鍵-秘密鍵ペアを持つ場合もある。存在する場合、（生の）公開鍵はデバイス ID との信頼された関連付けを持たない。デバイス製造者は、サポートされている場合、人間が読み取り可能な形式でコードを提供し、NFC を介したコードまたは公開鍵の読み取りをサポートし、または Provisioner のカメラを使用して QR コードとして読み取ることができる。
1.3認証
プロビジョニング手順には、Provisioner のユーザーが、プロビジョニングされるデバイス（Provisionee）がプロビジョニングする予定の物理デバイスであることを確認できるように設計された、認証 ステップが含まれる。これにより、人為的なミスや中間者攻撃の可能性から保護される。
ブルートゥース® メッシュ・プロファイル仕様のバージョン 1.0 では、認証 いくつかの形式が定義されている。上記の認証情報を利用する代わりに、乱数または文字列を生成することができ、エンドユー ザーは対応する列を入力しなければならない。たとえば、OOB認証 出力では、デバイスがサポートするアクションを使用して、必要なサイズのランダムに選択された 数値を出力するよう、被提供者に要求する。別の方法として、デバイスの製造元は、人間が読み取り可能な、または機械が読み取り可能な静的 OOB認証 コードをデバイスとともに提供することもできる。たとえば、カメラを搭載した Provisioner は、機器に印刷された QR コードをスキャンすることができる。また、Provisioner は、全ゼロ認証 値を使用して認証 受け入れることを選択することもできる。その後、プロビジョニング・ベアラ上で認証 値を含む確認交換が行われ、成功すると、被提供者が認証され、残りの手順が続行される。
1.4 実際的な問題
ブルートゥース® メッシュ1.0でサポートされている認証 オプションを使用するには、実用上の問題があります。Provisionee 機器が見えない、または見えにくい場合があり、オプションは、個々の機器に対 してエンドユーザーが直接操作する必要があります。さらに、LED を点滅させて認証 値を示すような動作は、実用的な観点からは、小さな数値で使用する場合にのみ適しています。小さな認証 値は、低レベルのエントロピーを提供し、特に安全ではない。長い数字列は、データ入力の必要性から負担となり、適切な表示を追加すると製品のコストが高くなる可能性がある。
これらの問題にアドレス するため、ブルートゥース® メッシュ v1.1 では、プロビジョニング手順の一部としてデジタル証明書の使用が導入されています。次のセクションでは、電子証明書の一般的な概要を説明し、次にデバイスのプロビジョニングに電子証明書がどのように使用されるかについて具体的に説明します。
1.5 電子証明書
デジタル証明書（略して証明書）は、主張されたエンティティの身元を検証するために使用される。ID に加えて、各エンティティは数学的に関連する鍵のペアを持つ。公開鍵は、セキュリティを損なうことなく、誰にでも自由に配布できる。対応する秘密鍵は決して公開されず、所有するエンティティのみが知っている。ID を検証する行為は認証呼ばれ、インターネットの世界では、証明書が、ドメイン名またはhost 名に基づいてサーバーを認証する主な方法である。デバイス証明書も同様に、特定のデバイスを識別するために使用される。たとえば、ブルートゥース® メッシュ・プロビジョニングでは、ID としてデバイス UUID と会社（製造者）名の組み合わせが使用される。
証明書は、さまざまなフィールドと値を含むデジタル文書である。X.509 標準は証明書文書の形式を定義しており、一般に使用されている。証明書は、ID とエンティティの公開鍵値をバインドし、サードパーティがその関連付けを検証して、通信相手のエンティ ティがその主張通りのエンティティであることを判断できるメカニズムを提供することで機能する。
証明書は誰でも作成することができるが、信頼できる根拠が確立されているものは、認証局（CA） と呼ばれる信頼できる組織によって発行される。CA は、ある ID を持つエンティティが特定の公開鍵値に関連付けられており（バインドされており）、 同じ鍵に他の ID がバインドされていないことを確認する。基本的に、CA はエンティティがその主張する人物であることを検証する。CA を信頼することで、その CA が発行したすべての証明書の信憑性を信頼することができる。
証明書の内容、証明書が作成される際の安全な手続き、発行組織のセキュリティ慣行はすべて、CA、ひいては CA が発行する証明書に対する信頼につながる。
証明書を作成する際、CAはその秘密鍵を用いて証明書本体のデジタル署名を生成し、証明書に署名を添付する。この発行者署名が存在することで、CAは証明書のエンティティ名と公開鍵の関連付けを承認していることになる。運用上およびセキュリティ上の理由から、CA は通常、1 つまたは複数の中間証明書のチェーンを作成し、チェーンの終端にある中間証明書を使用してエンドエンティティ証明書に署名する。
認証ために証明書を検証するには、認証 手続きを実行するエンティティは、CA のルート証明書を所有 し、すべての中間証明書を取得しなければならない。認証するエンティ ティは CA を信頼し、署名を検証することで、信頼する CA がその署名によってこのことを示したため、 証明書の ID 情報および公開鍵が信頼できると結論づけることができる。
2.Bluetooth Mesh証明書ベースのプロビジョニングについて
2.1 能力とメリット
証明書ベースのプロビジョニング機能 、プロビジョニング中にデジタル証明書をデバイス認証 基礎として使用することができ、デバイスUUIDと特定の公開鍵値との関連付けを安全に検証します。
証明書を使用してデバイスを認証する場合、プロビジョニング中にユーザがデバイスを物理的に見たり聞いたりできる必要はない。認証 プロビジョニング中に特定のデバイスとユーザーが直接対話することは要求されないので、認可されたUUIDのリストを組み立てたり、候補デバイス証明書のハッシュを作成したり、静的なOOBシークレットに依存し続けたりするなど、ネットワークに参加することを許可されたデバイスを認可するための他の方法が必要である。証明書は、多くの点でより優れたセキュリティを提供し、Output OOBのような方法に関連する低エントロピーに悩まされることはない。他のプロビジョニング認証 方法およびアクションを使用する際の実用的かつ潜在的なセキュリティ問題は、この機能軽減される。
2.2 テクニカル・ハイライト
2.2.1 デバイス証明書
プロビジョニング中に証明書ベースの認証 使用するには、メッシュ・デバイスにデバイス証明書と呼ばれる関連デジタル証明書が必要です。これはX.509形式の証明書で、X.509 Subject Nameフィールドにメッシュ・デバイスのUUID値が含まれています。デバイスの静的公開鍵も証明書に含まれる。証明書には、デバイスのベンダーと製品モデルの識別子が含まれることもある。
デバイス証明書は、サードパーティの CA またはデバイス・ベンダーの社内 CA のいずれかによって発行され、 署名される。証明書には、準拠する CA ポリシーを示すフィールドを含める。
2.2.2 機器証明書の入手可能性
未プロビジョニング・デバイス・ビーコンは、プロビジョニングの可用性を示すためにデバイスからブロードキャストされる。このタイプのビーコンには、OOBプロビジョニング情報の可用性と、それを取得できるソースを示すOOB 情報と呼ばれるフィールドが含まれる。ビット 7 が設定されている場合、デバイスが証明書ベースのプロビジョニングをサポートしていることを示す。
2.2.3 デバイス証明書の取得
Provisioner がProvisioning Invite PDU を送信する前に、適切なデバイス証明書を Provisioner が使用できるようにしておく必要があります。デバイス証明書はさまざまなソースから取得できます。
デバイスは、プロビジョニング・レコード（2.2.4 を参照）と呼ばれる新しい保存メカニ ズムを使用して、証明書自体およびオプションとして中間証明書を保存することができる。プロビジョニング・レコードには、インターネット・プロトコルを示す URI と、必要なときに証明書をダウンロードできるアドレス 含まれる。この仕様では、NFC タグやバーコードなどの他のソースを使用してダウンロード URI を提供する方法についても説明している。
証明書のダウンロードと検証は、Provisioner が行う。証明書の検証は、RFC5280 に従い、標準的なインターネット技術タスクフォース（IETF）手順に 従って実行される。完全な証明書チェーンの一部である中間証明書も、プロビジョニング・レコードに格納することができる。プロビジョナは、証明書署名チェーンが検証できるように、各デバイス・ベンダの CA ルート証明書をロードし、アクセスする仕組みを、直接またはhost オペレーティング・システムを通じて提供しなければならない。
新しい建物にメッシュネットワークを設置する場合など、状況によってはインターネットにアクセスできないことがあります。このような状況に対応するため、Provisioner は、新しいネットワークにデバイスをプロビジョニングする前に、デバイス証明書を事前にロードすることができる。このような証明書キャッシュの手順は、現在の機能 定義には含まれていない。
2.2.4 プロビジョニング記録
プロビジョニングレコードは、プロビジョニング中に使用される保存情報にアクセスするための読み取り専用のメカニズムを提供する。定義されたレコード・タイプがいくつかあり、それぞれ 16 ビットの数値レコード ID で識別される。たとえば、ID 値 0x0000 のレコードには証明書ベースのプロビジョニング URI が含まれ、ID 値 0x0001 のレコードにはデバイス証明書が含まれる。
新しいプロビジョニング・プロトコルPDUが定義され、プロビジョニング・レコードをリストまたは検索できるようになった。長いレコードは、PDUのオフセットとフラグメントサイズパラメータを使用して、一連のフラグメントとして取得される。
2.2.5 Bluetooth Meshのリモート・プロビジョニングと証明書
ブルートゥース® メッシュリモートプロビジョニング機能 、Provisionerから直接電波が届かない場所でも、デバイスのプロビジョニングが可能になります。これは、特に新しいネットワークを立ち上げる場合に実用的なメリットがあります。しかし、プロビジョニング対象のデバイスがユーザーから見えないこともあります。実際には、10階上の階にある場合もある！
Bluetooth Mesh Certificate-based ProvisioningはBluetooth Mesh Remote Provisioningと併用することで、この問題を解決することができる。
3.閉じる
ブルートゥース®メッシュ証明書ベースのプロビジョニングは、公開鍵インフラストラクチャを使用してデバイスを認証する業界標準のアプローチを提供します。証明書は、デバイスのネットワークへの参加を承認するエンドユーザーの負担を軽減し、不正なデバイスがネットワークに追加される可能性を低減します。この機能、Bluetooth Mesh Remote Provisioning 機能補完するもので、プロビジョニングされていないデバイスを、アプリケーション 直接の無線範囲内に置くことなくプロビジョニングできます。
