はじめに
IoTの時代、数多くの「スマート」デバイスが登場しています。KeyWe Smart Lockも例外ではありません。生活をより便利にするために、メカニカルロック機構とワンタイムのゲストコード生成、所有者がドアの近くにいる際のロック解除をはじめとした様々な追加機能の両方が含まれています。ただし、「スマートであること」と「セキュリティの担保」の両立は常に難しい問題なのです。
デバイスの概要
スマートロックは以下の主要パーツで構成されています：
- フロントパネル (スマートロックとの通信で使用)
- メカニカルロック (オンラインとオフライン両方で使用)
- バックパネル (電源の供給とロックの機械部分の駆動に使用)
フロント／バックの両方のパネルが接続されている場合、誰かがそれを解除しようとすると、アラームが鳴るように設定されます。
スマートロックでドアを解錠するためにはいくつかの方法が考えられます：
- 物理キーを使用した機械的な方法
- アプリケーションの使用 (追加の確認は不要)
- アームバンドの使用 (NFC-Mifare Classic)
スマートロックのハードウェア
デバイス内部を見ると、各ボードの目的が明確に示されます。
KeyWe – ボード
KeyWe – ボード（背面）
前面の1つは、ユーザ入力 (数値キーボードとRFIDチップ) を処理するためにのみ使用されます。 攻撃者がアクセスすることが不可能な裏側は、全てのアプリケーションロジックを処理します。シリアルおよびJTAGアクセス試行 (後者) では結果が得られませんでした。ただし、コンポーネントの識別により、STMマイクロコントローラーが使用されていることがわかりました。SWIMに公開されているポートの1つ (使用されているデバッグプロトコルであるシングルワイヤインターフェイスモジュール) が有効のままになっているようです。ピンにはんだ付けし、ST-LINKアダプターを使用した後、デバイスファームウェアをダンプすることができました。
全てを網羅しているわけではありませんが、ボード上で特定されたコンポーネントは以下のとおりです。
ブリッジの調査
ブリッジデバイスは、Wi-Fi経由でBluetooth Low Energyを介して処理されるロックを公開するためのものです。外観はかなり洗練されていますが、内部にはESP32ベースのボードがあります。ボードで興味を引くのは、白いパネルにあるピンです。
KeyWeブリッジ – 全体図
マルチメーターとピン配置図を観察した結果、ほぼ全てのピンを識別することができました。
KeyWeブリッジ – ピン配置の写真
ESP (暗号ペイロード) は広く使用されている技術で、読み取り保護、暗号化などが利用可能ですが、ブリッジではこのような機能は使用されていません。シリアルおよびJTAGアクセスは有効なままで、暗号化は使用されません。これは、以下のアウトプットで確認できます。
ファームウェアへのアクセスがいかに簡単だったかを踏まえると、このブリッジはこれまで特に注意を払われていなかったようです。
ソフトウェアのハッキング
次のステップに進み、通信とアプリケーションのレイヤーに移行します。公開資料に基づいて、スマートロックが付属しているパッケージに記載されているように、「Bluetooth Smart」を使用していることがわかります。これはBLE / BTLEの別名である「Bluetooth Low Energy」です。
おそらく、BLE検査に最も便利と思われるツールは、Nordic SemiconductorsのnRF Connectです。先に進む前に、Bluetooth Low Energyのいくつかの基本概念について簡単に説明します。
Bluetooth Classicと異なり、BLEには「検出可能なデバイス」という概念がありません。周辺機器と呼ばれる各デバイスは、受信可能範囲にいる人にメッセージ (広告と呼ばれる) を送信します。広告には、名前、アドレス (接続の確立に使用)、機能など周辺機器に関する様々な情報が含まれます。このようなデバイスは、グループ化されたエンティティのリストを公開します。特性には、読み取り (読み取りアクセス)、更新 (書き込みアクセス)、または値が変更されたことを他の接続先に通知 (アクセスを通知) できる値 (テキスト、番号など) を含めることができます。
KeyWe社のスマートロックは、「読み取りタイプ」と「通知タイプ」という2つの特性を持つ1つのサービスを公開します。これらは、スマートロックとの間でメッセージを送受信するために使用されると既に推定されています。しかし、それを検証する方法は1つだけ、モバイルアプリケーションを検査することです。ここでは、Androidアプリケーションについて説明します。
BLE関連の関数を検索すると、複数のメソッドが含まれているDoorLockNdkクラスを見つけることができます。NDKはNative Development Kitの略で、ネイティブ (コンパイル済み、アンマネージド) コードをJava (Java Native Interface、JNIを使用) にブリッジする方法です。
前述の各メソッドは、バイト配列を返します。大成功！私たちは金鉱を見つけました！もう少し詳しく説明すると、何らかの方法でメッセージを傍受した場合、それは無意味です。各メッセージは、送信前にAES-128で暗号化されます。ただし、そのクラスにアクセスできるため、暗号化の前にメッセージを傍受できてしまいます。こうして通信プロトコルを分析することができます。ただし、関数呼び出しを傍受する方法はあるのでしょうか？答えはかなり簡単、Fridaツールを使用することです。ここで技術をスキップし、引数をダンプして値を返す関数を作成します。コードは、GitHubリポジトリにあります。
Fridaを使用して得られた情報に基づいて、ロックとモバイルアプリケーションの間で交換されたメッセージのログを以下に示します。
注目すべき関数は、makeCommonKey、makeAppKey、makeDoorKeyです。これらは、アプリケーション内またはロック上で呼び出されますが、メッセージが直接送信されることはありません。
正確な思考プロセスはスキップされますが、関数makeAppNumberおよびmakeDoorNumberを使用して、2つのパーティ間で交換される値を生成することを指摘する必要があります。これは単純な「キー交換」プロトコルとして機能します。各サイドは値を生成し、他のカウンターパートに送信し、他の「番号」が受信されると、キーペアを計算できます。1つのキーは、ロック (makeDoorKey) から発信されるメッセージの暗号化／復号化に使用され、もう1つのキーはモバイルデバイス (makeAppKey) に使用されます。これらの各番号は、送信前に共通キーで暗号化されます。
一般的なmakeCommonKey呼び出し結果のリスト (共通キー値) は以下のとおりです：
(exec. idは、最初の実行、2番目の実行など、特定のデバイスに対する実行を示すために使用されます)
ここで見られるように、共通キーは実行間で変化しませんが、デバイスアドレスによって変化します。
それが重大な間違いなのです！全ての通信を復号化するために、2つの値のみが関係する構内キー交換が使用されるため、送信を傍受するだけで済みます。共通キーは、デバイスアドレスに基づいて簡単に計算できます。
これを行うには、キーが正確に計算される方法を知る必要もあります。これには、アセンブリで手を汚す必要があるため、正確なプロセスはここではスキップされます。ただし、それらを計算するためのコードは、前述のリポジトリで公開されています (ただし、重要な部分を削除することで無害化されます)。
これで、あなたは王国への鍵を手に入れたことになります！
メーカー側の反応
F-Secureがこの問題を開示した後、KeyWe社はこの問題を認識しており、積極的なコミュニケーションや対応に取り組んでいます。しかし、残念ながら同社のスマートロックにはファームウェア更新機能が備わっていないため、このセキュリティ上の問題はスマートロックそのものが交換されるまで続きます。しかし、同社の次世代製品ではこの問題は解消される予定です。また、次バージョンの製品にはファームウェア更新機能が搭載されるとのことです (リリース日など詳細は未定)。
まとめ
使用されるAESアルゴリズムは、暗号化に関しては事実上の標準であるため、KeyWe社がセキュリティに細心の注意を払っていないとは言えません。しかし、使用されるプロトコルは構内暗号と呼ぶべきものであり、業界において長く知られているように、これは決していい方法ではありません。さらに、メーカー側は脅威モデルについて漠然とした考えしか持っていなかったようです。開発者／アーキテクトが、スマートロックの近くにいる人なら誰でもデバイスアドレスが利用可能であることを認識していたならば、今回の問題は発生していなかったでしょう。
F-Secure／KeyWeの両社が今回のことから学んだ教訓は次のとおりです。
- 脅威モデルを理解する
- 構内暗号を開発／利用しない
- ツールを知り、そして使用することで膨大な時間が節約可能
- 一見安全なそうなデバイスにも詳細な分析を実行し、データのパターンを見ることが必要
カテゴリ