Bluetooth Mesh 証明書ベースのプロビジョニング

技術概要

目次を見る

リリース：	1.0.0
文書バージョン：	1.0
最終更新日：	2023年9月19日
著者：	マーティン・ウーリーBluetooth SIG エリック・アンデルリンド、カイトスプリング社 ハンヌ・マラット、シリコン研究所 オムカー・クルカルニ、ノルディック・セミコンダクター

改訂履歴

Version	Date	Author	Changes
1.0.0	September 19, 2023	Martin Woolley, Bluetooth SIG Erik Anderlind, KiteSpring Inc. Hannu Mallat, Silicon Laboratories Omkar Kulkarni, Nordic Semiconductor	Initial version

 

注 Bluetooth Mesh プロファイル仕様は名称が変更され、現在は次のように呼ばれている。Bluetooth Mesh プロトコル仕様と呼ばれるようになった。本書と関連論文でバージョン1.1仕様を参照する場合はこの名称を使用するが，バージョン1.0仕様を参照する場合は引き続きBluetooth Mesh プロファイル仕様書仕様と呼ぶことにする。

 

1.背景

Bluetooth Mesh 証明書ベースのプロビジョニングは、Bluetooth^® Mesh プロトコル仕様のバージョン 1.1 で導入された。Bluetooth Mesh Certificate-based Provisioning の機能と利点を十分に理解するには、Bluetooth Mesh バージョン 1.0 のいくつかの側面を理解する必要がある。本セクションでは、Bluetooth Mesh Certificate-based Provisioning の検討に役立つ文脈と背景を示す。

1.1 プロビジョニング

プロビジョニングは、デバイスがBluetooth Mesh ネットワークの一部となる手順である。プロビジョニングは、ネットワークの試運転または新しいデバイスの追加中にユーザーが実行する。プロビジョニングは、多忙な作業環境で、一般的にデバイスが物理的にインストールされた後に実行されることが多い。

1.2 デバイスの識別とクレデンシャル

プロビジョニングされていないデバイスは、一意のDevice UUIDで自身を識別する。また、工場で割り当てられた一意のプロビジョニング・コードや、静的な公開鍵-秘密鍵ペアを持つ場合もある。存在する場合、（生の）公開鍵はデバイス ID との信頼された関連付けを持たない。デバイス製造者は、サポートされている場合、人間が読み取り可能な形式でコードを提供し、NFC を介したコードまたは公開鍵の読み取りをサポートし、または Provisioner のカメラを使用して QR コードを読み取ることができる。

1.3 認証

プロビジョニング手順には、Provisioner のユーザーが、プロビジョニングされるデバイス（Provisionee）が、プロビジョニングしようとする物理デバイスであることを確認できるように設計された認証ステップが含まれる。これにより、人為的ミスや中間者攻撃の可能性から保護される。

Bluetooth^® Mesh Profile Specification のバージョン 1.0 では、いくつかの認証形式が定義されている。上記のクレデンシャルを利用する代わりに、乱数または文字列を生成することができ、エンドユー ザーは対応する列を入力しなければならない。たとえば、出力 OOB 認証では、被提供者が、デバイスがサポートするアクションを使用して、 必要なサイズの無作為に選択された数値を出力することが要求される。別の方法として、デバイスの製造者は、人間が読み取り可能または機械が読み取り可能な静的 OOB 認証コードをデバイスとともに提供することができる。たとえば、カメラを搭載した「プロビジョナ」は、デバイスに印刷された QR コードをスキャンすることができる。プロビジョナは、全ゼロ認証値を使用して認証を受け入れることも選択できる。その後、認証値を含む確認交換がプロビジョニング・ベアラ上で行われ、成功すると、被提供者が認証され、残りの手順が続行される。

1.4 実際的な問題

Bluetooth^® Mesh 1.0 でサポートされている認証オプションを使用するには、実用上の問題があります。Provisionee 機器が見えない、または見えにくい場所にある可能性があり、オプションは個々の機 器に対してエンドユーザーが直接操作する必要がある。さらに、LED を点滅させて認証値を示すような動作は、現実的には、小さい数での使用にしか適さない。小さな認証値ではエントロピーが低く、特に安全とは言えない。長い数字列は、データ入力の必要性から負担となり、適切なディスプレイを追加すると製品のコストが高くなる可能性がある。

これらの問題に対処するため、Bluetooth^® Mesh v1.1 では、プロビジョニング手順の一部としてのデジタル証明書の使用が導入されています。次のセクションでは、デジタル証明書の一般的な概要を説明し、次にデバイスのプロビジョニングにデジタル証明書がどのように使用されるかについて具体的に説明します。

1.5 電子証明書

デジタル証明書（略して証明書）は、主張されたエンティティの身元を検証するために使用される。ID に加えて、各エンティティは数学的に関連する鍵のペアを持つ。公開鍵は、セキュリティを損なうことなく、誰にでも自由に配布できる。対応する秘密鍵は決して公開されず、所有するエンティティのみが知っている。身元を確認する行為は認証と呼ばれ、インターネットの世界では、証明書が、ドメイン名またはホスト名に基づいてサーバーを認証する主な方法である。デバイス証明書も同様に、特定のデバイスを識別するために使用される。たとえば、Bluetooth^® Mesh プロビジョニングでは、デバイス UUID と会社（製造者）名の組み合わせを ID として使用する。

証明書は、さまざまなフィールドと値を含むデジタル文書である。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 デバイス証明書

プロビジョニング中に証明書ベースの認証を使用するには、mesh デバイスに、デバイス証明書と呼ばれる関連デジタル証明書が必要です。これはX.509形式の証明書で、X.509 Subject Nameフィールドにmesh Device 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 ルート証明書をロードし、アクセスする仕組みを、直接またはホスト・オペレーティング・システムを通じて提供しなければならない。

新しい建物にmesh ネットワークを設置する場合など、状況によってはインターネットにアクセスできないことがあります。このような状況に対応するため、Provisioner は、新しいネットワークにデバイスをプロビジョニングする前に、デバイス証明書を事前にロードすることができます。このような証明書キャッシュの手順は、現在の機能定義には含まれていません。

2.2.4 プロビジョニング記録

プロビジョニングレコードは、プロビジョニング中に使用される保存情報にアクセスするための読み取り専用のメカニズムを提供する。定義されたレコード・タイプがいくつかあり、それぞれ 16 ビットの数値レコード ID で識別される。たとえば、ID 値 0x0000 のレコードには証明書ベースのプロビジョニング URI が含まれ、ID 値 0x0001 のレコードにはデバイス証明書が含まれる。

新しいプロビジョニング・プロトコルPDUが定義され、プロビジョニング・レコードをリストまたは検索できるようになった。長いレコードは、PDUのオフセットとフラグメント・サイズ・パラメータを使用して、一連のフラグメントとして取得される。

2.2.5Bluetooth Mesh リモート・プロビジョニングと証明書

Bluetooth^® Mesh リモートプロビジョニング機能を使用すると、Provisioner から直接電波が届かない場所でもデバイスのプロビジョニングを行うことができます。これは、特に新しいネットワークを立ち上げるときに実用的な利点があります。ただし、プロビジョニングするデバイスがユーザーから見えないこともあります。実際、10階上の階にある場合もある！

Bluetooth Mesh 証明書ベースのプロビジョニングは、Bluetooth Mesh リモートプロビジョニングとともに使用することができ、この問題を解決する。

3.閉じる

Bluetooth^® Mesh 証明書ベースのプロビジョニングは、公開鍵基盤を使ってデバイスを認証する業界標準のアプローチを提供します。証明書は、ネットワークに参加するデバイスを認証するエンドユーザーの負担を軽減し、不正なデバイスがネットワークに追加される可能性を低減します。この機能は、Bluetooth Mesh の リモートプロビジョニング機能を補完するもので、Provisioner アプリケーションの電波の届く範囲にデバイスが直接いなくても、プロビジョニングされていないデバイスをプロビジョニングできます。