DARK MATTER

CDI Engineer's Technical Blog

続々 WiresharkのDissectorを使った独自プロトコル解析(TCP,UDP分割パケットの場合)

本稿では、Luaで独自プロトコルのDissectorを作る人のために、TCPとUDPの分割(フラグメント)パケットの再構築(リアセンブル)を説明します。

f:id:yasuikj:20200825183801p:plain

Dissectorって何?という人は、先にWiresharkのDissectorを使った独自プロトコル解析をやさしく解説してみましたを読んでください。

前々回は、符号なし整数、文字列を題材にDissectorを説明しました。 前回は、Bit列の解析や時刻の解析など様々なデータ型への対応や、エンディアン(Endian)の対応について説明しました。

これまでの内容を理解いただければ、1パケットの解析はできるようになったと思います。しかし、世の中にはデータサイズが大きく複数のパケットに分割されて送信されるプロトコルも存在します。今回、このような分割パケットのDissectorの作り方について解説します。

今回紹介する内容を理解いただくと、分割パケットに対応できるDissectorを作る力がつきます。
サンプルのキャプチャデータも添付するのでWiresharkを使って試してみてください。

技術部の安井です。長年、制御システムを開発した経験から、現在は制御システムセキュリティ向上に取り組んでいます。

前々回 前回とも、継続してアクセスいただいており、独自プロトコルを解析するためにDissectorを作成しようしている方が参考にしてくれているようです。記事を読みDissectorを作成する方が増えてくれていれば嬉しい限りです。
最近、前回ブログで「記載していないこと」と書いた「データサイズが大きく複数パケットに分割された場合のDissector」についての問い合わせをいただく機会がありました。TCPとUDPにおける分割パケットの解析方法の資料を探したところ、TCPに関しては多くの資料が見つかりましたが、UDPに関しては理解しやすい資料をさくっと見つけることができませんでした。このためUDPに関して解説するブログを書いてみることにしました。

対象読者

前々回、前回の以下ブログ内容を理解している方。かつ、何らかのプログラム言語を使ったことがあり配列や連想配列が何かを理解している方。
io.cyberdefense.jp
io.cyberdefense.jp

できるようになること

複数のパケットに分割されたパケットのDissectorの作成

TCPのパケット分割について(いちおう書いておきます)

TCPはストリーム型の通信であり、送信サイズや通信環境によりTCPの仕組みでパケットが分割されて送信される場合があります。このため一般に公開するDissectorでは分割パケットの対応はお作法として実施しておいた方がよいと思います。

TCPの分割パケットの解析については、pinfo.desegment_len = DESEGMENT_ONE_MORE_SEGMENT というキーワードを覚えておけば、必要な際にサンプルを探せばいろいろな解説資料がみつかると思います。わかりやすく親切に解説してくれていると思った2つのURLを紹介しておきます。
Wiresharkで独自プロトコルの解析 - Qiita
Wiresharkの解析プラグインを作る ssmjp 201409 P24,25

UDPのパケット分割について(ここから本題です)

制御システムではTCPよりオーバヘッドの小さなUDPを使う場面が多くみられ、大きなデータをUDPで送信する場合、送信プログラムにて1パケットで送信可能なサイズで分割して送信することが多いです*1

本稿では以下の例を用いてUDPの分割パケットの解析について解説します。

  • UDPで2つのパケットに分割(フラグメント)された内容を再構築(リアセンブル)して表示する。

送信したいデータは、図1に示した30byteのデータとする。


f:id:yasuikj:20200826171526p:plain
図1:UDPを使って送信するデータのイメージ
Size部は10進数の26,データ本体部はasciiコードのa〜zです。

UDPの1つのパケットのフォーマットは図2に示したとおりであり、データ部として最大16byteしか格納できないとする。

f:id:yasuikj:20200825172927p:plain
図2:UDPの1パケットのフォーマット

30byteのデータを図2のフォーマットで送信するには、パケットを分割する必要があるため、図3に示したように2つのパケットに分割して送信する。

f:id:yasuikj:20200825172939p:plain
図3:送信したいデータをUDPの2つのパケットに分割したイメージ

UDP分割パケットのDissector

この章は、本ページ内に記載したDissectorのサンプルコードをudp_div.luaという名称で保存し、udp_div.txtのパケットを読み込んでみてください。

proto = Proto("udp_div","udp_div")

Ident_F  = ProtoField.new("Ident","Ident",ftypes.UINT16)
DivNo_F  = ProtoField.new("DivNo","DivNo",ftypes.UINT16)
DivMax_F = ProtoField.new("DivMax","DivMax",ftypes.UINT16)
DataSize_F  = ProtoField.new("DataSize","DataSize",ftypes.UINT32)
Data_F   = ProtoField.new("Data","Data",ftypes.STRING)

proto.fields = { Ident_F, DivNo_F, DivMax_F, Size_F ,DataSize_F, Data_F}

-- 初期化処理
function proto.init()
  fragments = {} -- 1パケットずつに分割されたパケットのデータ部を保存するバッファ。各パケット毎に保存する
  concats = {}   -- 分割パケットをマージした本体データを保存するバッファ。DivMax目のパケット処理時に保存する
end

-- Dissector  解析のメイン部分
function proto.dissector(buffer, pinfo, tree)

  local ident_no   = buffer(0,2):uint()    -- Ident識別子
  local division_no  = buffer(2,2):uint()  -- DivNo
  local division_max = buffer(4,2):uint()  -- DivMax

  if pinfo.visited == false then    -- 当該パケットを処理するのが初めての場合
    --注意:このpinfo.visitedで判定しないとWiresharkの画面でパケットをクリックする度処理が動いてしまう
    if division_no == 1 then
      local data_size = buffer(6,4):uint() -- データ本体のトータルサイズ
    end
    local reassembly_byte     -- 組み立て後のデータバイト列

    -- fragmentsを保存するテーブルの枠を生成
    if fragments[ident_no] == nil then
      fragments[ident_no] = {}
    end
    if fragments[ident_no][division_no] == nil then
      fragments[ident_no][division_no] = {}
    end

    -- パケットのUDPデータ部のサイズから先頭の独自ヘッダサイズ(6byte)を除いた部分をfragmentsに記憶
    fragments[ident_no][division_no] = buffer:bytes(6,buffer:len()-6)

    -- 分割パケットの最後なら、分割パケットをまとめたバイト列を生成しconcatsに記憶
    if (division_no == division_max ) then
      -- 保存用バイト列を生成
      reassembly_bytearray = ByteArray.new()
      -- 分割数分処理
      for key, value in ipairs(fragments[ident_no]) do
        -- バイト列をマージ
        reassembly_bytearray:append(value)
      end
      -- 分割数分マージしたバイト列をconcatsに記憶
      concats[pinfo.number] = reassembly_bytearray
      -- 各分割パケットのバイト列を保存したエリアは解放
      fragments[ident_no] = nil
    end
  end

  tree:add(Ident_F,buffer(0,2))    -- Ident表示
  tree:add(DivNo_F,buffer(2,2))    -- DivNo表示
  tree:add(DivMax_F,buffer(4,2))   -- DivMax表示

  -- 分割パケットのまとめがある場合
  if concats[pinfo.number] ~= nil then
    pinfo.cols.info = "merged data"
    buffer1 = concats[pinfo.number]:tvb("merged data")
    tree:add(DataSize_F,buffer1(0,4))     -- Size部分表示
    tree:add(Data_F,buffer1(4,data_size)) -- Size部分以降のデータ本体表示
  end
end

--  Dissectorを使用するUDPポート番号を指定する。
udp_table = DissectorTable.get("udp.port")
udp_table:add(4352, proto)

テスト用データのパケットキャプチャデータをテキスト形式としたものを以下に記載します。
記載内容をudp_sample.txtというファイル名で空のテキストファイルに転記し保存した上、Wiresharkのメニューの[ファイル]-[開く]からudp_sample.txtを選択してください。

+---------+---------------+----------+
01:03:35,089,675   ETHER
|0   |08|00|27|db|63|e0|08|00|27|63|e1|01|08|00|45|00|00|32|5f|41|40|00|40|11|94|50|c0|a8|01|01|c0|a8|01|02|f7|51|11|00|00|1e|47|59|00|33|00|01|00|02|00|00|00|1a|61|62|63|64|65|66|67|68|69|6a|6b|6c|

+---------+---------------+----------+
01:03:35,146,884   ETHER
|0   |08|00|27|db|63|e0|08|00|27|63|e1|01|08|00|45|00|00|30|5f|41|40|00|40|11|94|50|c0|a8|01|01|c0|a8|01|02|f7|51|11|00|00|1c|47|33|00|33|00|02|00|02|6d|6e|6f|70|71|72|73|74|75|76|77|78|79|7a|

+---------+---------------+----------+

このDissectorでテスト用データをWiresharkで表示したものを図4に示します。2パケット目の"Data" 部にabcd〜xyz とマージされたデータが表示されているのがわかると思います。

f:id:yasuikj:20200825174646p:plain:w290f:id:yasuikj:20200825174703p:plain:w290
          図4:1パケット目と2パケット目のWiresharkでの表示

最後に、2パケット目の"Data"部をクリックしたときの表示を図5に示します。ソースコード上concats[pinfo.number]:tvb("merged data")とした部分が、画面の最下部の左側Frameバイト列の枠の右横にmerged data(30bytes)として別枠で表示されているのがわかると思います。

f:id:yasuikj:20200825174719p:plain
図5:リアセンブルしたデータ部を表示したもの

まとめ

本稿では、Luaを使ってUDPの分割パケットのDissectorを作る方法を説明しました。

本稿がUDPの分割パケットの解析に困っている方の助けになれば幸いです。



本稿を作成するにあたり参考とさせていただいた資料です。
osqa-ask.wireshark.org

補足

本記事を作成したところ、ある同僚の方より
「独自ヘッダーの情報だけでリアセンブリすると、クライアントが複数存在する場合バグりそうです。1対1を基本とする独自プロトコルや運用はよくありますが、dissectorとしては多対多で正しく動作できるよう、サーバー/クライアントのIP/ポートの組み合わせを使うとよさそうだと思います。」
とのアドバイスとともに、対策したサンプルソースをいただけました。上記以外の元ソースとの相違としては、pinfo.cols.infoの書き換えはやめており分割全パケットでマージ結果を表示するようにしている点と、パケットの到着順序逆転にも対応するため分割パケット組み立て用に確保したエリアの解放やめています。こちらの方が便利な場合も多々あると思いますので合わせて公開しておきます。ソースの解説は載せてませんのが興味ある方は読み解いてみてください。

*1:様々な理由がありますがここでは理由の説明は割愛します。

続きを読む

ふぉっふぉっふぉ、今日はワシのかんがえた最強の入退室システムの話じゃ。

はじめに

石垣です。

前回の記事続編としてIoT特有のセキュリティ対策具体例をご紹介したいと思います。

io.cyberdefense.jp

弊社ではハードウェア診断を行っているため、お客様から具体的な対策を教えてほしい等の相談を受けますが、診断報告書による大まかな脆弱性修正方法および参考資料、報告会での技術的な回答、相談を受けた際のコンサルティングのみとなっており実際に製品を作るお仕事はしておらず、お見せする実装がございませんでした。

もしかするとセキュリティ診断会社は指摘事項を見つけるだけで、実際のところ設計とか実装とかできないでしょ!!!???と思われているかもしれませんので実証もかねてIoT特有のセキュリティ対策を行った入退室システムを本気で作ってみました。

f:id:tatac1:20200731113809j:plain

Yubikey 5 NFCをカードリーダにかざすことでドアが開く仕組みとなっています。

皆さんが利用されているSuica/PASMO等FeliCaを利用したICカードと同じ使い勝手ですが、内部の仕組みや利用技術は全く異なります。

www.youtube.com

※モザイク適当なのとデモ向けなのでPINが初期値なのはご愛嬌です

昨年9月頃から作業を開始し今年の2月頃に基本構成が完成しました。

実は今年2月にカルフォルニアで行われたRSAカンファレンスで展示も行っております。

作ったもの

今回はNFCカードリーダ側とドアの開閉制御を行うサーバ側を含め開発しました。

設計は一から考えると大変なので米国連邦政府の規格であるPhysical Access Control System (PACS1)

pacs.idmanagement.gov

BACnet

http://www.bacnet.org/Bibliography/BACnet-Today-06/28889-Ritter.pdf

の規格を参照し実装しています。

しかしながら参照規格では、NFCカードリーダ、認証サーバ等をどのようにセキュアにすべきかIoT特有のセキュリティ対策について記述はないため以下の実装を行っています。

  • デバイス認証、署名のために証明書を利用、秘密鍵はTPMを利用し保護(ユニーク性/真正性の担保)
  • Secure bootで改ざんを検知(完全性の担保)
  • Full Disk Encryption(FDE)対応でディスクデータを暗号化(機密性の担保)
  • 各NFCカードリーダ、認証サーバ間はwebsocket over TLS1.3通信(機密性/完全性の担保)

f:id:tatac1:20200721154333j:plain
構成図

f:id:tatac1:20200720165157p:plain
シーケンス図

通信はすべてTLS1.3となっているので、クライアント認証を突破しない限りTLSより上位レイヤーヘの攻撃は到達しません。したがってアプリケーションおよびアプリケーションミドルウェアに脆弱性が見つかったとしても正規証明書が無い限り攻撃は到達しない為、結果的に緩和策となります。

弊社では過去に警備会社や重電メーカの入退室管理システムを利用していましたが、全く他のシステムと連動できなかったためActive Directory/LDAPとの連動を前提として設計し運用を楽にする集中一括管理の仕組みを取り入れています。

またログに関しても解錠要求記録は電子署名されているため改ざん対策のログとして利用可能です。

上記の動画で見ていただいたハードウェアですがTPMが組み込まれた産業システム向けのCPUボードを利用しており耐久性も考慮しています。

最終的なイメージ

f:id:tatac1:20200720214142p:plainf:id:tatac1:20200720214210p:plain

上記イメージのディスプレイにはkindle等で利用されているe-ink社のディスプレイを備える予定です。

今回e-ink ディスプレイを採用した理由ですが

  • 電力が喪失しても画面が表示可能であることから、有事の際の避難経路等のメッセージ表示が可能
  • 視認性のよいお知らせ、案内表示が可能
  • タッチパネルが備わっているため簡単な操作が可能

となります。

秋月や千石等では、様々な電子ペーパーディスプレイが販売されていますが、6インチ、解像度:758 x 1024 pixels,、タッチパネル、LEDバックライト、応答速度すべてを備えたディスプレイは販売されていないため、実はe-ink社からディスプレイの調達を行い、表示やバックライト、タッチパネル向けの制御ボードを自社開発しました。

f:id:tatac1:20200731124840j:plain
ディスプレイコントローラボード

またサーバも同様にTPMが組み込まれた産業システム向けのCPUボードを利用しており汎用製品で構成しているのでコストは専用製品と比べ廉価です。

電気錠を開ける制御ですがFPGAで回路を組みつつ、制御ボードをフルスクラッチから作りました。

f:id:tatac1:20200731113802j:plain
左からIO制御ボード+FPGAボード、サーバ側ボード

なお初期バージョンの電気錠制御はリレースイッチでした。

f:id:tatac1:20200804112639j:plain
リレースイッチ

ドッグフードを食べる

作成した入退室管理システムを実際に利用するために、社内すべての扉に工事を行っています。

美和ロック等2一般に販売されている電気錠であれば制御が可能な構成となっており、既存のカードリーダを置き換え3ることが可能です。

動画に映っていた黄色いケーブルは光ファイバーです。光ファイバーを利用することでLANケーブルの100m制約は無くなります。動画内で利用しているメディアコンバータでは最大50kmまで延長することが可能であり、ノイズ、落雷等による影響を抑えることが可能です。

動画ではドアを解錠したYubikey 5 NFCでWindowsにスマートカード認証ログオンを行っています。この認証の仕組みはActive Directoryに備わっている標準機能ですので、サーバ、クライアントともに別途ソフトウェアのインストールを行う必要はありません。またウェブアプリケーションへのアクセスの際にもクライアント証明書認証を行っています。

LinuxでもSSO認証(kerberos認証)が可能であることを社内では検証済みです。なおコロナの影響で検証はまだ行えていませんがActive Directoryと連動しMacでもスマートカード認証+SSOが行える事はApple公式資料で確認済みです。したがってWindows同様にMac標準機能でも実現可能です。

弊社ではYubikey内の証明書とOS標準機能を利用して

  • 802.1xを利用しWiFi, LAN接続時にEAP-TLS認証
  • VPN接続時のクライアント証明書認証
  • SMTP接続時のクライアント証明書認証
  • ウェブにおけるクライアント証明書認証

等を実現し物理セキュリティ、ネットワークセキュリティからアプリケーションレイヤーまでをカバーするパスワードレス認証、アカウントの窃取対策を行っています。

したがって

  • ドアや壁の破壊できればもちろん侵入は可能ですが、入退はYubikeyが無い限り侵入はとても難しいです。
  • 掃除の方が気軽にLANポートやWiFiにつなごうとしても、Yubikeyが無い限りネットワークにつながらないので社内ネットワークに接続することはとても難しいです。
  • 社内ネットワークに接続できたとしても、Yubikeyが無い限りアプリケーションレイヤーへのアクセスすることはとても難しいです。

弊社でのYubikey活用具体例の記事がありますので興味がある方はご覧ください。

io.cyberdefense.jp

io.cyberdefense.jp

余談:Suica/PASMO等のFeliCaを利用した入退室管理システム製品 ~ IDmの闇

IDmを使った認証の問題をご存じの方は読み飛ばしていただければと。

入退室管理システムではよく使われるICカードとしてFeliCaが利用されていますが、利用/実装方法を誤った製品のセキュリティ問題が指摘されています。

IPA:入退管理システムにおける情報セキュリティ対策要件チェックリスト www.ipa.go.jp

itmedia: なりすましの問題について記事 blogs.itmedia.co.jp

またフェリカネットワークスから公式に注意が行われています。

引用: モバイル FeliCa IC チップにおける製造 ID(IDm)の取り扱いについてhttps://www.felicanetworks.co.jp/assets/pdf/rule_plugin_idm.pdf

· モバイルFeliCa ICチップのIDmは、比較的容易に読み出しが出来るコードであり、FeliCa技術方式のセキュリティ機能をフルに活用したものではありません。セキュリティの観点から次の点にご注意ください。 · IDmは誰でも読み出すことができますので、これのみを用いたアプリケーションは、正規カードになりすました偽造カードやカードエミュレータにより攻撃を受ける可能性があります。 · 通信路での暗号化をしておりませんので、盗聴される可能性があります。 · セキュリティが要求されるアプリケーションにおいては、FeliCa技術方式の相互認証機能の利用を推奨します。 また、ユニークなIDを必要とするFeliCaサービスアプリケーションを開発する際には、IDmではなくサービス事業者がサービスレベルで付番管理するコードを利用することを推奨します。

実際にIDmのみを参照し認証を行っている製品を弊社ではいくつかの製品で確認しています。

FeliCaのセキュアエレメント領域を利用し無い限りセキュアな認証を実現することは難しく、以下の様なSDKを利用する必要があります。

www.sony.co.jp

FeliCaは公開鍵4ではなく共通鍵AES/DESを利用しています。共通鍵を利用し高速処理を実現することと引き換えに安全な鍵管理・保護の仕組みが必要となります。

www.sony.co.jp

そのためNFCカードリーダには、AES/DES等の鍵をセキュアに保存するSAMチップを利用する必要があります。

www.sony.net

また一部入退室管理システムのスタンドアロン方式ではカードリーダは電気錠をコントロールするIOコントロールボードへ結線され、開錠、施錠信号が送信される仕組みとなっている構成があります。つまりカードリーダからIOコントロールボードへ伸びたケーブルの通信をタッピングしリプレイ攻撃が有効となるケースも考えられます。

通信ケーブルのタッピングは弊社の過去記事で取り上げていますので、現実的な脅威と考えられます。

io.cyberdefense.jp

皆さんのオフィスの入退室システムはどのような方式で開閉を行っているか把握されているでしょうか?

お手持ちのPASMOやSuica等を入退室以外で利用されているのであれば何処で利用したか把握されているでしょうか? IDmが何処で読み取られたか把握されているかたはいるでしょうか?

もし現在ご利用の入退室管理システムに「お手持ちのICカードで○○機能がご利用できます」と記載がある場合どのような認証方式であるか穿ったみかたをした方がよいかもしれません。

物理はセキュリティ対策の根幹であり非常に重要ですので、是非一度はIPAから提供された資料を参考にチェックを行ってみることをおすすめします。

  • 本サイトに掲載されている商品またはサービスなどの名称は、各社の商標または登録商標です。
  • 本サイトはリスク把握・対策を目的としており、著作権侵害や不正アクセス行為等の教唆、幇助を目的としたものではありません。

  1. ※FIPS140対応の暗号モジュールを利用し、PACSテストにパスをすれば米国連邦政府でも利用可能となります。国産では残念ながらPACS認証を取得した入退室管理システムは有りません。

  2. ゴール等他社の電気錠もFPGA側の変更で対応可能となっています。

  3. LANケーブルと電源ケーブルがあればカードリーダ側を取り替えるだけとなります。

  4. 公開鍵はサポートしていないためWindows/Macのスマートカード認証、TLSクライアント認証,802.1x等の利用はOS標準機能では実現できません。

IoTセキュリティでこれだけは押さえておきたい三つのリスク ~ 不都合な真実

はじめに

こんにちは石垣です。

社会的に大きな影響を及しているCOVID-19によって、「ニューノーマル」と呼ばれる、新しい常識や常態への順応・適応が否が応でも求められるようになりました。

社会の仕組みが「ニューノーマル」仕様となるべくIoTが生活に組み込まれて身近になると同時に、IoTのセキュリティ対策はどうなっているのだろうかと思われた方はいるのではないでしょうか?

今回はIoTにおけるセキュリティについて理解するべき三つの基本リスクと対策について理解いただく事を目的として本記事を執筆しました。

本記事の対象者と得られる知見としては

  • IoTサービス/デバイスの利用者であれば、利用しようとしている/利用しているIoTのセキュリティ対策について評価
  • IoTデバイス/サービスに関係する企画者/エンジニア/保守・運用者は現状/今後のセキュリティ対策の妥当性判定や対策方法の原理

となります。

IoTの定義には揺らぎがありますので本記事では「物理的な目的で利用されるセンサー/アクチュエータを備え、ネットワークにつながるデバイス・サービス」とします。

IoT特有のセキュリティリスクとは?

IoTが活用される場所の一例

f:id:tatac1:20200720165423j:plain

  • トンネル/橋
  • 車両
  • 病院
  • etc...

身近なIoT活用の例としてお住まいの自宅に設置されたスマートメータなどはわかりやすい事例と思います。

またバイタルデータ等を取得するものから、薬液注入ポンプなど医療機器がIoTとして活用されている事例があります。

まずはじめにIoTとネットワークサービス(ウェブサービス等)で根本的に異なるのは、IoTデバイスが管理者/製造者の手元から物理的に離れます。結果、物理的に分散するということは、その分物理制約上、セキュリティ対策が分散することとなります。

攻撃者視点で考えると、クラウドサービスをホスティングするサーバへ物理的にアクセスする事はデータセンターへの侵入等乗り越えるハードルが高いですが、上記に列挙した場所に設置されたIoTデバイスであれば鹵獲や物理的ないたずらは難しくないことが想像いただけるかとおもいます。

したがってIoTのセキュリティリスクは「物理的に離れた」ことによってクラウドサービスには存在しない新たなセキュリティリスク(特有のセキュリティリスク)が生まれます。

セキュリティ対策ガイドラインや記事

既に様々なIoTのセキュリティに関するガイドライン/記事等が公開されております。

www.ipa.go.jp

www.iotac.jp

monoist.atmarkit.co.jp

www.intellilink.co.jp

コンプライアンスの観点は上記のガイドラインにお任せし、本記事では上記ガイドラインでは触れられない視点(攻撃者の視点から)からIoT全般に見られるセキュリティリスクについて説明を行いたいと思います。

セキュリティリスク - 範囲外について

製造の過程(いわゆるサプライチェーン)によるチップ、基板等に加えられた攻撃は本記事ではスコープ外としてセキュリティリスクの説明を行います。

一例として

io.cyberdefense.jp

ほかにもサイドチャネル攻撃等様々な攻撃手法が有ります。

なおHardware Trojanは論文、書籍等様々資料が公開されていますので、興味がある方は関連キーワードで調べてみてください。

IoT特有のセキュリティリスク

攻撃者は鹵獲すると物理デバイスに好きなようにアクセスできますので何でもありです。例えば

  • ディスク/メディアを解析
  • ディスク内のソフトウェア改造
  • 通信のタッピング

が可能となります。

弊社社員が執筆した記事が参考となるかとおもいますのでご紹介します。

io.cyberdefense.jp

io.cyberdefense.jp

io.cyberdefense.jp

io.cyberdefense.jp

io.cyberdefense.jp

以降に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でしか筆者は見たことがなく、利用者はどういったテクノロジー/技術を利用してセキュリティ対策が行われているのか知る由もないので不都合な真実であると筆者は考えます。

一方攻撃者はデバイスが鹵獲できればカジュアルに物理攻撃からのサイバー攻撃が可能であり、防御側は分が悪く非常に悩ましい課題です。

もしガイドライン等でセキュリティモジュールを利用しなければいけないと定められた場合、セキュリティを理解でき正しく設計・実装が出来る開発者が限られてしまい、結果製品の選択が狭まる事が考えられます。法令・ガイドライン等は何処でバランスを取るべきか悩ましい選定/基準定義になると考えられます。

民生品の場合、以下リンクで紹介されているカルフォルニア州の「デバイスのデフォルトパスワードを禁ずる」法令で制限する等が現状のベター解決策であるかと筆者は考えます。

jp.techcrunch.com

以降、具体的な対策の一例をご紹介します。

具体的対策の一例

如何に攻撃者のコストを上げるかを考えた場合、前項で記載したセキュリティリスクの対策としてはワンチップ化、Intel TXT、TrustZone、TPM、セキュリティチップ等の利用が前提となります。

もちろんそれらのテクノロジーを利用したとしても完全無欠の対策とはなりませんが、対策のレベル感としてはNSA, DoD(国防省)等でも要件として記載されるものと考えていただくといいかと思います。

以下のNSAのサイトでは、納品にかかる基準概要が記載されています。

apps.nsa.gov

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の脆弱性 speakerdeck.com

TPMの脆弱性 tpm.fail

Intel TXTの脆弱性 www.intel.com

ワンチップ化の実装は対策案の中で特に難易度が高いため、三つの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の詳細にについて書籍が無料で公開されていますので、以下からダウンロード可能です。

link.springer.com

TPMを利用したデバイスのユニーク性担保

TPM製造元を信じることを前提として

TPMの内に封入されたEK鍵を利用し、AIK鍵を作ってユニーク性を担保します。

AIK鍵を使って、クライアント認証、署名、暗号化等を行います。

TPM内に秘密鍵を保存することで認証情報の保護を行います。

EK鍵 ~ TPMごとに一意な電子証明書鍵が製造者によって生成されており鍵の変更および削除は不可。

AIK鍵 ~ CSRをEK鍵で署名し、認証局でEKの署名検証後、認証局署名を行った電子証明書鍵、クライアント認証、署名、暗号化等で利用

IEEE. 802.1ARでDevIDとして規格が策定されており参考になるかと思います。

1.ieee802.org

TPMを利用した実行ソフトウェア/生成データの完全性担保

TPMのPCRを利用してブート状態を確認することが可能です。AIK鍵を利用しPCR値に署名を行い、認証側等で署名済みのPCRデータを検証することで、IoTデバイスの状態を検証可能です。

参考となるOpenSource Projectがあるので紹介します。

github.com

さらに生成した何らかのデータ(例:数量、読み取った商品コード、センサーの値、画像等)に署名を行って情報収集側に送信を行う事でデータの完全性担保が可能となります。

通信先の証明書の署名認証局はNVRAM(Non Volatile RAM)に書き込み、変更不可とすることでroot証明書の改ざん対策を行うことが可能となります。

TPMを利用したデータの機密性担保

Windowsではデータの暗号化をBitLockerで行っています。

詳しくは以下に記載があります

docs.microsoft.com

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 にも参考となる投稿もあるので、ご紹介します。

security.stackexchange.com

続編: 不都合な真実の詳細と、IoT特有のセキュリティリスク対策やってみた。

不都合な真実をもう少し解説しつつ、実際にIoT特有のセキュリティリスク対策を行ったシステムを作ってみましたので次回ご紹介します。

[次回記事リンク貼り付け予定]

io.cyberdefense.jp

余談: Raspberry Piで対策ってどうすればいい?

評価検証フェーズでよく利用されるRaspberry Piですが、商用でそのままソフトウェアを利用したといったニーズがあるかとおもいますので過去に調べた結果をご紹介します。

結果: 現状としては、残念ながらRaspberry Piでは三つのセキュリティリスク対策をすべて行うことは不可能です。

認証情報秘匿やディスク暗号化だけは以下のデバイスを利用することで実現は可能です。

筆者も実際に購入し利用したことがある二つのデバイスを紹介します。

LetsTrust TPM for Raspberry Pibuyzero.de

www.zymbit.com

しかしながらRaspberry Piではroot of trust = シリコンレベルで真のsecure bootは行えません。

www.raspberrypi.org

blog.nviso.eu

上記のTPMやセキュリティモジュールを利用したデバイスが有ったとしても筆者が攻撃者の立場で考えると、SDカードを取り出しddダンプを行う、暗号化されていないbootプロセスの改ざんを行う、認証情報秘匿やディスク暗号化等に必要な情報を窃取するなど、あとは好きなようにTPM、Securityモジュールに保存されたデータを利用したり内部データを覗くなどを考えます。

その点BitlockerやFileVault2よく出来た仕組みです。

強いです。

LinuxはSecure boot+Full Disk Encryption等の対策を行っていないとsingle user modeでrootがとれます

具体的な方法としては以下が参考になると思います。

www.raspberrypi.org

IoTデバイス、サービスにRaspberry Piが使われてる場合は上記三つのセキュリティリスクをベースに利用ケースに応じた具体的な脅威の例が想像できるかとおもいます。

  • 本サイトに掲載されている商品またはサービスなどの名称は、各社の商標または登録商標です。
  • 本サイトはリスク把握・対策を目的としており、著作権侵害や不正アクセス行為等の教唆、幇助を目的としたものではありません。

  1. 弊社では業務で様々なデバイスを診断していますがNDAがあるため開示不可となっています。また筆者個人として利用する製品は購入し三つのリスク/観点で判断し利用の可否をしています。

株式会社サイバーディフェンス研究所 / Cyber Defense Institute Inc.