はじめに
こんにちは石垣です。
社会的に大きな影響を及しているCOVID-19によって、「ニューノーマル」と呼ばれる、新しい常識や常態への順応・適応が否が応でも求められるようになりました。
社会の仕組みが「ニューノーマル」仕様となるべくIoTが生活に組み込まれて身近になると同時に、IoTのセキュリティ対策はどうなっているのだろうかと思われた方はいるのではないでしょうか?
今回はIoTにおけるセキュリティについて理解するべき三つの基本リスクと対策について理解いただく事を目的として本記事を執筆しました。
本記事の対象者と得られる知見としては
- IoTサービス/デバイスの利用者であれば、利用しようとしている/利用しているIoTのセキュリティ対策について評価
- IoTデバイス/サービスに関係する企画者/エンジニア/保守・運用者は現状/今後のセキュリティ対策の妥当性判定や対策方法の原理
となります。
IoTの定義には揺らぎがありますので本記事では「物理的な目的で利用されるセンサー/アクチュエータを備え、ネットワークにつながるデバイス・サービス」とします。
IoT特有のセキュリティリスクとは?
IoTが活用される場所の一例
- トンネル/橋
- 家
- 車両
- 病院
- etc...
身近なIoT活用の例としてお住まいの自宅に設置されたスマートメータなどはわかりやすい事例と思います。
またバイタルデータ等を取得するものから、薬液注入ポンプなど医療機器がIoTとして活用されている事例があります。
まずはじめにIoTとネットワークサービス(ウェブサービス等)で根本的に異なるのは、IoTデバイスが管理者/製造者の手元から物理的に離れます。結果、物理的に分散するということは、その分物理制約上、セキュリティ対策が分散することとなります。
攻撃者視点で考えると、クラウドサービスをホスティングするサーバへ物理的にアクセスする事はデータセンターへの侵入等乗り越えるハードルが高いですが、上記に列挙した場所に設置されたIoTデバイスであれば鹵獲や物理的ないたずらは難しくないことが想像いただけるかとおもいます。
したがってIoTのセキュリティリスクは「物理的に離れた」ことによってクラウドサービスには存在しない新たなセキュリティリスク(特有のセキュリティリスク)が生まれます。
セキュリティ対策ガイドラインや記事
既に様々なIoTのセキュリティに関するガイドライン/記事等が公開されております。
コンプライアンスの観点は上記のガイドラインにお任せし、本記事では上記ガイドラインでは触れられない視点(攻撃者の視点から)からIoT全般に見られるセキュリティリスクについて説明を行いたいと思います。
セキュリティリスク - 範囲外について
製造の過程(いわゆるサプライチェーン)によるチップ、基板等に加えられた攻撃は本記事ではスコープ外としてセキュリティリスクの説明を行います。
一例として
ほかにもサイドチャネル攻撃等様々な攻撃手法が有ります。
なおHardware Trojanは論文、書籍等様々資料が公開されていますので、興味がある方は関連キーワードで調べてみてください。
例
IoT特有のセキュリティリスク
攻撃者は鹵獲すると物理デバイスに好きなようにアクセスできますので何でもありです。例えば
- ディスク/メディアを解析
- ディスク内のソフトウェア改造
- 通信のタッピング
が可能となります。
弊社社員が執筆した記事が参考となるかとおもいますのでご紹介します。
以降にIoT全般で共通する具体的なセキュリティリスクをご紹介します。
デバイスのユニーク性および真正性に関するリスク
ネットワークを経由で認証を行う場合、認証する側から見ると(データ収集側)誰が接続し認証してきたかを確認することが重要となります。
人間がIDとパスワードを入力する場合とは異なり、IoTの場合自動で認証を行う方式になると考えられますので、この自動認証の仕組みをどのようにするかは悩まれた方も多いかと思います。
攻撃者はなりすましを行う事ために、まず物理デバイスのディスク/メディアを解析し、ハードコーディング、難読化データから認証情報の窃取を試みます。
攻撃者のモチベーションはターゲットのアカウント権限であり、なりすますとその権限であらゆる事が可能となるからです。
コードに隠蔽しても動的解析を行う等で変数やレジスタの値を見てしまえばいくらでも解析は可能です。
またディスクが暗号化されていなければカジュアルにデータを解析が出来たりします。
脅威の例としては、自宅にあるスマートメーター固有番号が他のメータになりすまされると請求を行う際に大変困ることが想像できるかとおもいます。
医療機器であれば、A患者に利用されているものが、実はB患者のものになりすまされると事故につながるかと考えられます。
実行ソフトウェア/生成データの完全性に関するリスク
IoTデバイスが想定したとおりのソフトウェアが実行されていることをデータ収集側としては期待します。すなわち改ざんされた状態ではない事をデータ収集側は把握する必要があります。またIoTデバイス生成データが改ざんされていないことをデータ収集側としては期待します。
攻撃者は改ざんを行う事ために、まず物理デバイスのディスク/メディアを解析し、ソフトウェア/生成データの改ざん、通信ケーブルのタッピング等を行い通信の改ざんを試みます。
攻撃者のモチベーションは望み通りの動作をIoTデバイスに行わせることです。
OSからは見つけることができないレイヤー(UEFI, firmware, bootloader等)にマルウェアを仕込まれると、OS側からは何もするすべがないです。
またディスクが暗号化されていなければカジュアルに解析/改造が行えたりもします。
脅威の例としては、自宅のスマートメーターが正しく計量している「ふり」や改ざんされた計量データを送信をされると大変困ることが想像できるかとおもいます。
医療機器であれば、A患者で計測されているバイタルデータが正しく計量している「ふり」や改ざんされた場合事故につながるかと考えられます。
データの機密性に関するリスク
IoTデバイスがデバイス内にデータを保存した場合や、データを送信した場合に機微な情報は暗号化されているべきだと利用者は期待するかもしれません。
通信内容から機微な情報が解析/窃取されたり、デバイスの破棄時にデータが第三者に解析/窃取されないように暗号化が必要となります。
攻撃者のモチベーションは、システム内部をつまびらかにして興味がありそうな情報を覗いてふむふむしたい、悪用できる情報の窃取をしたい、悪用の結果を確認するためにデータを覗くなどです。
攻撃者の用意した証明書を信用させるために、通信先の証明書のチェックで必要となる認証局のroot証明書を書き換えてしまえば、いくらでも暗号通信内容を覗くことが可能になります。
脅威の例としては、自宅のスマートメーターの計量データが平文で通信していると在宅の有無等の推測を容易となる、デバイス内に平文保存されていると在宅の傾向が判明するなどのプライバシーの侵害が行えるようになりえる等です。
医療機器であれば、A患者で計測されているバイタルデータ等が平文通信されている場合や、デバイス内に平文で保存されていると医療情報の漏洩事案に該当すると考えられます。
結論: IoT特有のセキュリティリスク対策
結論を拙速に書き下すと、IoT特有のセキュリティリスク対策は
- 公開鍵基盤を利用した電子証明書の発行/更新/失効の仕組み
- TPM/Trust Zone/Intel TXT等のハードウェアセキュリティ機能
を利用することが必要となります。
電子証明書は真正性、完全性、機密性を確保する技術として既にインターネットで広く利用されており説明は不要かとおもいます。
電子証明書の利用に加え、電子証明書で利用される公開鍵暗号方式において秘密鍵を窃取などから保護しつつデバイス上からのみセキュアに利用可能とするための対策として耐タンパー性、良質な乱数、暗号処理を備えたハードウェアセキュリティモジュールを利用することが必要となります。
ハードウェアセキュリティモジュールは、利用者は秘密鍵を知ることなく利用することだけが可能となる仕組みを提供し秘密鍵の生データには直接アクセスは出来ない回路となっています。例としては「IC付きクレジットカードを利用する際に暗証番号を入力」が皆さんになじみがある利用ケースです。
現在利用もしくは提供されているIoTにおいて「電子証明書」、「TPM/Trust Zone/Intel TXT等のハードウェアセキュリティ」のテクノロジー/技術がIoTデバイスで利用されていなければ、既に説明した三つの「デバイスのユニーク性および真正性に関するリスク」「実行ソフトウェア/生成データの完全性に関するリスク」「 データの機密性に関するリスク」いずれか、もしくはすべてが攻撃者からみると管理策の弱点=脆弱であると解釈されます。
本記事を読まれた方は既に感づかれているかもしれませんが、IoT特有のセキュリティ対策を行う事は実はとても大変です。
この三つのリスクに正しく対策・実装されたIoTデバイスは一部の製品1でしか筆者は見たことがなく、利用者はどういったテクノロジー/技術を利用してセキュリティ対策が行われているのか知る由もないので不都合な真実であると筆者は考えます。
一方攻撃者はデバイスが鹵獲できればカジュアルに物理攻撃からのサイバー攻撃が可能であり、防御側は分が悪く非常に悩ましい課題です。
もしガイドライン等でセキュリティモジュールを利用しなければいけないと定められた場合、セキュリティを理解でき正しく設計・実装が出来る開発者が限られてしまい、結果製品の選択が狭まる事が考えられます。法令・ガイドライン等は何処でバランスを取るべきか悩ましい選定/基準定義になると考えられます。
民生品の場合、以下リンクで紹介されているカルフォルニア州の「デバイスのデフォルトパスワードを禁ずる」法令で制限する等が現状のベター解決策であるかと筆者は考えます。
以降、具体的な対策の一例をご紹介します。
具体的対策の一例
如何に攻撃者のコストを上げるかを考えた場合、前項で記載したセキュリティリスクの対策としてはワンチップ化、Intel TXT、TrustZone、TPM、セキュリティチップ等の利用が前提となります。
もちろんそれらのテクノロジーを利用したとしても完全無欠の対策とはなりませんが、対策のレベル感としてはNSA, DoD(国防省)等でも要件として記載されるものと考えていただくといいかと思います。
以下のNSAのサイトでは、納品にかかる基準概要が記載されています。
In 2007 the DoD Chief Information Officer issued a policy memorandum, which requires that "all new computer assets (e.g. server, desktop, laptop, and PDA) procured to support the DoD enterprise include a Trusted Platform Module (TPM) version 1.2 or higher where such technology is available."
なおTPM/TrustZone/Intel TXTを利用した場合でも完全ではなく過去に脆弱性が報告されております。
TrustZoneを利用したTEEの脆弱性
TPMの脆弱性
Intel TXTの脆弱性
ワンチップ化の実装は対策案の中で特に難易度が高いため、三つのIoT特有のセキュリティリスク対策ではコモンクライテリアやFIPS140の認証が取得されており仕様が公開されているTPMチップ(ディスクリート)もしくはfTPMボード(ファームウェアベース)を利用する方法がまず最初に考えられると思われます。
弊社は、TPM仕様標準化などを行なっており実装事例も多数公開しているTrusted Computing Groupのメンバーであるため、TPMを利用した対策方法について紹介したいとおもいます。
TPM(Trusted Platform Module)について
ざっくり説明するとIC付きクレジットカードと同様の耐タンパー性、暗号/乱数生成機能を持ち、改ざん検証等の固有のユースケースにも対応可能なチップです。
はなしが若干それますが今年4月からIC機能が組み込まれたクレジットカードのみが利用可能と運用が変わりました。理由としては磁気スキミングの事故が後を絶たないためです。経緯等興味がある方はこちらの記事を参照ください
もとい、大抵のTPMチップはCommon Criteria EAL4, FIPS 140-2に対応しています。
Trusted Computing GroupでTPMの仕様が策定されています。
TPMの詳細にについて書籍が無料で公開されていますので、以下からダウンロード可能です。
TPMを利用したデバイスのユニーク性担保
TPM製造元を信じることを前提として
TPMの内に封入されたEK鍵を利用し、AIK鍵を作ってユニーク性を担保します。
AIK鍵を使って、クライアント認証、署名、暗号化等を行います。
TPM内に秘密鍵を保存することで認証情報の保護を行います。
EK鍵 ~ TPMごとに一意な電子証明書鍵が製造者によって生成されており鍵の変更および削除は不可。
AIK鍵 ~ CSRをEK鍵で署名し、認証局でEKの署名検証後、認証局署名を行った電子証明書鍵、クライアント認証、署名、暗号化等で利用
IEEE. 802.1ARでDevIDとして規格が策定されており参考になるかと思います。
TPMを利用した実行ソフトウェア/生成データの完全性担保
TPMのPCRを利用してブート状態を確認することが可能です。AIK鍵を利用しPCR値に署名を行い、認証側等で署名済みのPCRデータを検証することで、IoTデバイスの状態を検証可能です。
参考となるOpenSource Projectがあるので紹介します。
さらに生成した何らかのデータ(例:数量、読み取った商品コード、センサーの値、画像等)に署名を行って情報収集側に送信を行う事でデータの完全性担保が可能となります。
通信先の証明書の署名認証局はNVRAM(Non Volatile RAM)に書き込み、変更不可とすることでroot証明書の改ざん対策を行うことが可能となります。
TPMを利用したデータの機密性担保
Windowsではデータの暗号化をBitLockerで行っています。
詳しくは以下に記載があります
Macでは以下のペーパーが公開されています。
https://www.apple.com/ca/mac/docs/Apple_T2_Security_Chip_Overview.pdf
※両方secure bootに対応してます。
Linuxではどうなるかというと……と記事を書こうと思ったら産総研から以下の資料が公開(若干古いですが)されていたので参考になるかとおもいます。
https://trustedcomputinggroup.org/wp-content/uploads/JRF-WSDec2014_4.-AIST.pdf
- 改ざん対応 = PCR機能/P27
- 鍵の隠蔽 = TPM non-volatile storage/P28
- ディスク暗号化 = 鍵の隠蔽の応用
Stackexchange にも参考となる投稿もあるので、ご紹介します。
続編: 不都合な真実の詳細と、IoT特有のセキュリティリスク対策やってみた。
不都合な真実をもう少し解説しつつ、実際にIoT特有のセキュリティリスク対策を行ったシステムを作ってみましたので次回ご紹介します。
[次回記事リンク貼り付け予定]
余談: Raspberry Piで対策ってどうすればいい?
評価検証フェーズでよく利用されるRaspberry Piですが、商用でそのままソフトウェアを利用したといったニーズがあるかとおもいますので過去に調べた結果をご紹介します。
結果: 現状としては、残念ながらRaspberry Piでは三つのセキュリティリスク対策をすべて行うことは不可能です。
認証情報秘匿やディスク暗号化だけは以下のデバイスを利用することで実現は可能です。
筆者も実際に購入し利用したことがある二つのデバイスを紹介します。
しかしながらRaspberry Piではroot of trust = シリコンレベルで真のsecure bootは行えません。
上記のTPMやセキュリティモジュールを利用したデバイスが有ったとしても筆者が攻撃者の立場で考えると、SDカードを取り出しddダンプを行う、暗号化されていないbootプロセスの改ざんを行う、認証情報秘匿やディスク暗号化等に必要な情報を窃取するなど、あとは好きなようにTPM、Securityモジュールに保存されたデータを利用したり内部データを覗くなどを考えます。
その点BitlockerやFileVault2よく出来た仕組みです。
強いです。
LinuxはSecure boot+Full Disk Encryption等の対策を行っていないとsingle user modeでrootがとれます
具体的な方法としては以下が参考になると思います。
IoTデバイス、サービスにRaspberry Piが使われてる場合は上記三つのセキュリティリスクをベースに利用ケースに応じた具体的な脅威の例が想像できるかとおもいます。
- 本サイトに掲載されている商品またはサービスなどの名称は、各社の商標または登録商標です。
- 本サイトはリスク把握・対策を目的としており、著作権侵害や不正アクセス行為等の教唆、幇助を目的としたものではありません。
-
弊社では業務で様々なデバイスを診断していますがNDAがあるため開示不可となっています。また筆者個人として利用する製品は購入し三つのリスク/観点で判断し利用の可否をしています。 ↩︎