F-SecureがKeyWe製品の脆弱性を指摘、BLE通信傍受で第三者が解錠可能に
あるスマートロックの脆弱性から考える、IoTのセキュリティ課題
2019年12月16日 07時00分更新
フィンランドのセキュリティ会社F-Secure（エフセキュア）は2019年12月11日、韓国KeyWe（キーウィー）社が開発／販売するスマートロック「KeyWe Smart Lock」に脆弱性があることを発表した。この脆弱性を悪用することで、第三者がスマホアプリとスマートロック間のBLE（Bluetooth Low Energy）通信を傍受して鍵を取得し、ドアの解錠／施錠などができてしまうという。
「KeyWe Smart Lock」のWebサイト
F-Secureでは8月にKeyWeへの脆弱性報告を行い、これまでソフトウェアパッチの検証などで協力してきたという。調査に当たったF-Secureの担当者は、「KeyWeは決してセキュリティをおろそかにしていたわけではない」と説明する。脆弱性が生じた背景を、メールインタビューで詳しく聞いてみた。
クラウドファンディングで人気を集めたが……
KeyWe Smart Lockは、KeyWe社が「Kickstarter」や「Indiegogo」などのクラウドファンディングを通じて製品化したスマートロックだ。専用のスマホアプリを使って、NFC（スマホ本体の接触）やワンタイムパスワードなど数種類の方法で解錠／施錠できるのが特徴。Kickstarterにおいては、3226人の支援者（バッカー）を獲得し、55万8833ドル（6000万円強）の資金調達に成功している。
Kickstarterの画面。「史上最高にスマートな（かしこい）スマートロック！」というキャッチフレーズが書かれている
調査メンバーであるF-Secure Consultingのクリストフ・マーシニアック氏は、筆者とのメールインタビューにおいて「KeyWeはセキュリティをおろそかにしていたわけではない」と強調した。たとえばスマホアプリとスマートロックの間の通信は、AES 128ビットの暗号化で保護されている。
「ただし、残念ながらセキュリティ機構の設計で失敗しており、せっかくのセキュリティ対策が台無しになってしまった」（マーシニアック氏）
メールインタビューに応じた、F-Secure Consultingのクリストフ・マーシニアック（Krzysztof Marciniak）氏
脆弱性発見までの流れはこうだ。まず同氏は、KeyWeのスマホアプリを解析した。ここで発見した暗号化通信にかかわる関数に目を付け、関数呼び出しをフックしてメッセージ内容を見てみた。すると、アプリとスマートロック（ハードウェア）の双方で値を生成し、AESの共通鍵で暗号化したうえで交換し、その後のやり取りではこの生成した値を暗号／復号鍵として使っていることを割り出した。これはKeyWeが独自実装したシステムだ。
スマホアプリとスマートロックの間でメッセージをやり取りし、解錠／施錠などの処理を行う（画像はF-Secure Labsのブログより）
問題は、この共通鍵がスマートロックのBluetoothアドレスに基づいて生成されていたことである。Bluetoothアドレスは、デバイス名やアドバタイジングパケット（BLE接続が可能であることを周囲のデバイスに知らせる無線信号）に含まれている。一方で、共通鍵の生成アルゴリズムはアプリの解析から割り出せる。したがって、2つを組み合わせれば比較的簡単に共通鍵は解読できる。
あとは、ターゲットの玄関から15メートル範囲（BLE通信が届く範囲）に傍受用デバイスをひそかに設置して、家主が施錠／解錠する通信を盗聴。ここで得たBluetoothアドレスから共通鍵を生成し、それを使ってスマートロックを操作するだけだ。
「傍受用デバイスのチップやハードウェアは、日本円だと1,000円程度で揃えられるので簡単に制作できる」（マーシニアック氏）
F-Secureの制作したデモビデオでは、正規ユーザーが解錠するそばに攻撃者が忍び寄り、小さなデバイスで通信を傍受している
もうひとつ、スマホとスマートロックの間のBLEペアリング手続きが認証なしの“Just Works”方式になっていたのも問題だと、マーシニアック氏は説明する。一般的にJust Works方式は、ヘッドホンやマウスといった入出力装置を持たないBluetoothデバイスのペアリングで採用される。こうしたデバイスならば問題も少ないが、スマートロックが誰でも勝手にペアリングのは大きな問題だろう。これを防ぐのがアプリレベルでの認証システムだが、前述したような脆弱な仕組みでは意味をなさない。
マーシニアック氏は、残念ながら現時点では、KeyWe Smart Lockへの攻撃を防ぐ回避策はないと話す。そもそも同製品にはファームウェアの更新機能が実装されておらず、脆弱性の改修が不可能な状態だ。KeyWe社は、新規製造ロットから修正を行うとしているが、そのリリースがいつになるのかはわからないとマーシニアック氏は語る。本稿執筆時点で、KeyWe社からの公式発表も確認できていない。
現行ユーザーがいまできる防御法は、スマホアプリでの解錠／施錠をあきらめて旧来の物理鍵に戻すか、オプションであるタッチパッド入力での認証機能を使うことだけだ。
セキュアなIoT環境を実現させるために
今回のケースから見えてくるのは、開発ベンダーのセキュリティに対する認識不足だ。通信の暗号化技術は採用したものの、そもそもの暗号鍵を生成する仕組みが脆弱であるなど、そのほかのセキュリティ施策が見過ごされている。“なんちゃって独自鍵交換システム”からしても、通信さえ強固な暗号化方式で保護すれば対策は万全、という誤った認識が垣間見える。
BLEは、バージョンが上がるたびにペアリング方式や暗号化通信、認証方法などの脆弱性が修正され、強固なものになっている。少なくともバージョン4.2（2014年）以降は、より強力な公開鍵暗号方式と認証を組み合わせたセキュアな接続方法、デバイスのアドレスをアドバタイジングしないモードなど、さまざまな強化が図られた。これらをうまく活用できていれば、KeyWe Smart Lockも“スマートじゃないロック”にならずに済んでいたかもしれない。
とは言うものの、IoTデバイス側がいくら最新バージョンで安全性を確保しても、ユーザーのスマホ側がそれに対応しているとは限らない。より多くのユーザーに使ってもらうために、古いバージョンの脆弱な方式を採用するという判断もありうる。
「それに、いくら頑張ってセキュリティを強化しても、悲しいことにそれ自体が製品の売上に直結するわけではない」。特に予算が少なく、時間もあまりかけたくないスタートアップやベンチャーなどが、セキュリティよりも“実”を優先するという苦渋の決断をすることもあるだろうと、マーシニアック氏は理解を示す。
「それでも、セキュリティで妥協はしてほしくない」。それがマーシニアック氏の訴えだ。古い＝脆弱なバージョンをサポートするにしても、設計段階から想定されるリスクを洗い出して対策し、製品のリリース後はパッチ修正や更新などで継続して取り組むことで、セキュアな運用は可能だ。
「セキュリティ対策は慎重さが求められ、複雑でもある。そこをサポートできるのが、私たち専門家。もっと頼ってほしい」
