Key2.0: オープンソースのBluetooth IoTドアロック

Key 2.0とは?

Key 2.0(略して Key20)は、Bluetooth IoTドアロックコントローラーです。従来の電動ドアロックをスマートドアロックに変換し、物理的な鍵なしでスマートフォンから開けることができます。したがって、Key20はIoT時代の現代版物理鍵、つまり名前が示す通り、鍵の2.0バージョンです。

Key20は2つの部分で構成されています:

  1. Key20ドアロックコントローラー:このデバイスは電動ドアロックに物理的に接続され、BLE無線接続を介してモバイルアプリケーションと通信します。

  2. Key20モバイルアプリケーション:ドアを開けるためのユーザーインターフェースを提供し、BLEを介してドアロックコントローラーと通信します。

         [ モバイルフォン w/ ]
         [    Key20 アプリ    ]
               |
               | Bluetooth Low Energy (BLE) 接続
               |
    

    |—[ Key20 ドアロックコントローラー ]—[ 電動ドアロック ]—| | [ デバイス ] | | | | | | | |———————-(電源)———————–| ( 12 VAC )

下の図は、Key20ドアロックコントローラーとスマートフォンで動作するKey20アプリケーションを示しています。

https://github.com/duerrfk/key20/raw/master/images/key20_app_and_door_lock_controller.jpg

以下のビデオを視聴して、Key20の動作方法を簡単に理解できます:

Key 2.0 ビデオ

Key20の主な特徴は次のとおりです:

  • 高度なセキュリティメカニズム(楕円曲線ディフィー・ヘルマン鍵交換(ECDH)、HMAC)を使用して攻撃を防止します。
  • ソフトウェアとハードウェアがオープンソースで、安全メカニズムのオープンソース実装も提供します。セキュリティに隠し事はありません!アプリケーションとドアロックコントローラーのソースコードと、Eagleファイル(回路図と基板レイアウト)も提供します。
  • 友好的な製造者:入手しやすく安価な標準コンポーネント(nRF51822 BLEチップ、標準電子部品)、製造が簡単な回路基板、オープンソースのソフトウェアとハードウェア設計を使用しています。
  • BLE対応のAndroid 4.3以降のモバイルデバイスと互換性があります(もちろん、それ以上のバージョンもサポートしています)。他のモバイルOS(例:iOS)への移植も直接的に可能です。
  • ソフトウェアとハードウェアのライセンスはそれぞれApache License 2.0およびCERN Open Hardware License 1.0の下で自由に提供されています。

セキュリティの概念

ドアロックには当然、無許可の開錠要求を防ぐためのセキュリティメカニズムが必要です。そのため、Key20は次の最先端のセキュリティメカニズムを実装しています。

HMACを使用して開錠要求の認証

すべての開錠要求は、鍵ハッシュメッセージ認証コード(HMAC)を使用して認証されます。BLE接続を通じてドアロックコントローラーに接続するたびに、ドアロックコントローラーは16バイトのランダム数(nonce)を生成します。ランダム数はモバイルアプリケーションに送信されます。モバイルアプリケーションはランダム数と共有鍵を使用して512ビットのHMACを計算し、それを256ビット(HMAC512-256)に切り捨てて、ドアロックコントローラーに送信します。ドアロックコントローラーもランダム数と共有鍵に基づいてHMACを計算し、2つのHMACが一致する場合のみドアが開きます。

ランダム数は1回の開錠要求にのみ有効であり、リプレイ攻撃を防ぎます。これは、攻撃者が無線チャンネルを嗅ぎ取り、後で嗅ぎ取ったHMACを再生してドアロックコントローラーを開けるのを防ぎます。実際、BLE無線通信は暗号化されていませんが、暗号化は必要ありません。なぜなら、キャプチャされたHMACはリプレイ時には無効になるからです。

さらに、ランダム数は15秒間のみ有効であり、中間者攻撃を防ぎます。中間者がHMACをインターセプトした後、すぐに転送せず、認証ユーザーが離れた後にHMACをドアロックコントローラーに送信してドアを開ける場合です。時間ウィンドウが15秒間のみ(さらに短縮可能)であるため、この攻撃は無駄です。なぜなら、認証ユーザーが依然としてドアの近くにいるからです。

なお、認証プロセス全体には重量級の非対称暗号化関数は含まれておらず、軽量なハッシュアルゴリズムのみが使用されます。これにより、nRF51822マイクロコントローラー(ARM Cortex M0)を搭載したドアロックデバイスで非常に高速に実行でき、ドアの開閉が遅延しません。

ランダム数に関して、以下の点に注意する必要があります。まず、nRF51822チップには熱雑音からランダム数を生成する乱数生成器が含まれており、ランダム数は高品質、つまり真のランダム数であるべきです。攻撃者が建物内に物理的にアクセスしている場合、Bluetoothチップを冷却して熱雑音によるランダム性攻撃を減らすことは関連性がありません。

次に、128ビットのランダム数は合理的なセキュリティを提供します。1ミリ秒ごとに1回の開錠要求(非常に悲観的な仮定!)と100年間の操作を仮定し、保護が必要なリクエストはn = 2^42個未満です。128ビットのランダム数を使用すると、m = 2^128の可能なランダム数値があります。その後、バースデー問題を使用して、少なくとも1つのリクエストが共有のランダム数に一致する確率p、または反対に、リクエストが共有のランダム数と一致しない確率を計算できます。n « mのケースでは、p(n,m) = 1 - e((-n2)/(2*m))であり、n = 2^42およびm = 2^128の場合、実際には0です。たとえn = 2^52(1マイクロ秒ごとにリクエスト;実際にはBLEでは不可能)であっても、p(252,2128) < 3e-8、これは雷に打たれる確率とほぼ同じで、約5.5e-8です。

楕円曲線ディフィー・ヘルマン鍵交換(ECDH)を使用した鍵交換

鍵の共有部分は、ドアロックコントローラーとモバイルアプリケーションの間での共有鍵を確立することです。共有鍵を持っている人は誰でも建物に入ることができるため、ドアロックコントローラーとKey20アプリケーションだけが鍵を知っていることを確認する必要があります。そのため、Curve 25519に基づく楕円曲線ディフィー・ヘルマン(ECDH)鍵交換を使用します。ドアロックコントローラーは建物内に取り付けられており、ドアロックによって保護されています。したがって、許可されたユーザー(建物の所有者)だけが物理的にドアロックコントローラーにアクセスできます。

最初に、ユーザーはドアロックコントローラーのボタンを押して鍵交換モードに入ります(画像の赤いボタンのようなもの)。その後、モバイルアプリケーションとドアロックコントローラーは、楕円曲線25519に基づく異なる鍵ペアを計算し、公開鍵を交換します。公開鍵は誰でも知ることができます。双方の公開鍵と自分の秘密鍵を使用して、ドアロックコントローラーとアプリケーションは同じ共有鍵を計算できます。

Curve 25519およびARM Cortex-M0用に最適化されたMicro NaClプロジェクトのCurve 25519アセンブリ実装を使用すると、鍵ペアと共有鍵をnRF51822 BLEチップ(ARM Cortex M0)上でサブ秒単位で計算できます。

さらなる措置がない場合、DH(ディフィー・ヘルマン鍵交換)は中間者攻撃に対して脆弱です。中間者がモバイルアプリケーションとドアロックコントローラー間の通信を積極的に操作することができます。この攻撃によって、中間者は自分の公開鍵をドアロックコントローラーとアプリケーションの両方と交換し、中間者とドアロックコントローラーの間に1つの共有鍵を確立し、中間者とモバイルアプリケーションの間に別の共有鍵を確立します。この攻撃を防ぐために、鍵交換後にモバイルアプリケーションとドアロックデバイスの両方に共有鍵のチェックサム(ハッシュ)を表示します。ユーザーは視覚的にこれらのチェックサムが同じであることを確認します。もし同じであれば、中間者攻撃は発生していません。なぜなら、中間者はドアロックコントローラーとモバイルアプリケーションの同じ共有鍵を計算することができないからです(ドアロックコントローラーとモバイルアプリケーションの秘密鍵は依然としてプライベートです)。ユーザーは鍵が一致したことを確認した後に、ドアロックコントローラーとアプリケーションのボタンを押します。ユーザーだけがドアロックコントローラーに物理的にアクセスできることを忘れないでください。ドアロックは建物内に取り付けられ、ドアロックによって保護されています。

以下の図は、鍵交換後に表示される共有鍵のチェックサムを示しています。ユーザーは、ドアロックコントローラーの緑色のボタンとアプリケーションの確認ボタンを押すことで、この鍵を確認します。

https://github.com/duerrfk/key20/raw/master/images/key20_keyexchange_checksum.jpg

標準のBluetoothセキュリティを使用しない理由