テクノロジーのはざま

はじめに

とりあえずの情報源

・DDoS攻撃の踏み台

・Webカメラで覗かれる

「中華ウェブカメラ」のセキュリティについて https://r00tapple.hatenablog.com/entry/2017/08/12/050252

・初期PWから変わっていないWebカメラが世界中で観られている(た)

　SHODAN https://www.shodan.io/

 

現状の課題

1. 開発者が必要だと考えても、経営側が許さない (確率的な話しで費用対効果、損益に関わる)
2. 売切りビジネスとは整合性が悪い (サポート、フォロー費用を予め想定する必要がある)
3. アップデート機能が脆弱性を引き起こす (製品設計と同レベルでOTAは考えないといけない)
4. 既存HWでは太刀打ちできないことが多い (RoTが無い機器はもう無理)
5. 中途半端なセキュリティはセキュリティの世界ではやらない方がマシ (独自暗号、独自セキュリティ機構、メンテナンスフリーセキュリティ、はあり得ない)
6. 実装に長けたセキュリティ専門家がいない ((過去経験の)セキュリティ評論家はそれなりに多い。)
7. セキュリティがらみのプレイヤーが自身の観点で語ってしまう (セキュリティ部分機能の提供者)

開発側の現状　(※開発と言っても範囲が広い。ここではChip(SoC)開発)

・セキュリティ業界では、「Security by Design」と言われるが、真面目にすると開発費、開発期間が倍増する

・セキュリティ専門家が多く無い (セキュリティ評論家は多い)

・「Security by Design」の手引き書がほとんど無い　→ Arm社のドキュメントが一番進んでいる？

 

SoC関連のセキュリティトピック

SoCのセキュリティ対応のドキュメント "Trusted Board Boot Requirements CLIENT (TBBR-Client) Armv8-A"

・TrustZoneのSecure Applicationは、この要件を満たしていないとセキュリティ的に辛い

・2018年(5年前)のArmv8-A を使ったSoCのTEEの考え方に基づくBootプロセスについて書かれたガイドラインのドキュメント

・PDF 49ページ

1. 概要
2. Trusted Boot プロセスの概要 (Firmware Codeの認証、復号化)　※非対象鍵暗号
3. ソフトウェアアーキテクチャ
4. ハードウェアアーキテクチャ
5. Trusted Bootの要件表

TrustedFirmware-A (TF-A)

OP-TEE

TBBR-Clientの概要

Software Architecture

TBBR-Clientで説明しているセキュリティシステムの構成。

Exception LevelがEL0〜3、S-EL0,1に分けられて、それぞれ、Trusted World, Non-Trusted World領域の重なりで機能がラベル付けされている。

 

 

Trusted Base System Architecture の例

TBBR-Clientのドキュメントでは例として図が提示されるだけで、内部の詳細の説明は無い。

エンジンとかあれば、セキュリティ領域の定義に従ってDMAとかに関わるセキュリティ構成は自前でちゃんと考えなければならない。

 

 

 

Trusted Boot Processの概要

Power On後 (Cold RESET後)は Trusted World での処理が行われる。

Trusted Boot Processの各ステップで、信頼の連鎖が拡張される。

Trusted Boot ROMの段階で、OTAに関わる機能は実装しておかないといけない。

 

 

終わりに

IoTセキュリティの取っかかりとして、SoCが持っているハズの Secure Bootに関して、Arm社のTBBR-Clientドキュメントの図をトレースしていった。

IoTセキュリティは、それを司る人達でいろいろなアピール、アプローチがなされているが、統合的にソリューションとして情報がそれなりにまとまっているのはTBBR-Clientぐらいだろう。

しかしながら日本でこのドキュメントの知名度はあまり高く無いように思われる。

3月1,2日と松山でやっていた「サイバーセキュリティシンポジウム道後2018」に行ってきた．

今年のテーマはIoTセキュリティ，BlockChainだったけど，参加者のレベルや分野の違いもあってか，脅威情報の喚起中心で，じゃ具体的にどうすりゃいいのかという話しは期待していたがやっぱり少なかった．

アカデミック，警察の方は情報セキュリティの動向を知る上でいい機会なのかもしれないが，大部分が情報システムやインフラ系の企業参加者は若干アウェイな感じだったのではないかと思う．

横浜国立大学の吉岡先生の話は説得力あって，IoT脆弱性対策の一環で，ハニーポッドやハニーカメラでアタック素行を分析したり，脆弱性見つけたらまず是正して，事後に周知徹底のために間違った設定を発表するという，ある意味大人な対応が安心して聞けた．

ナイトセッションの総括の時に慶應の土井先生から叱られてしまったハードウェア・ハッキングは(ホワイト・ハッキング行為は目的じゃなく付随的な手段であって)その方法の公表も，正しい手順で慎重にしなさいということだろう(これは，周りの年配層への戒めもあるような気がする．)．

要は，ホワイト・ハッカーだけでなく，ブラック・ハッカーやハッカー予備軍の役に立ってしまう情報は相当慎重に扱わないといけないということだろう．

ただ，先頭切って情報を公開して同士を増やそうとしている若手の能力や今のモチベーションも尊重すべきだと思うので，IoTのペネトレーションテストは難しい課題である．

Webのペネトレーションと同様，作ったり売ったりしている会社からの依頼ならばペネトレーションテストとしてのハッキングは構わないが，自発的なハッキングやそれらの情報の公開は，避けるようにしないといけないのだろう．

また，最近のCoinCheck騒動もあって，ナイトセッションで2コマもBlockChainの枠があった．

(さすがに今のパターンマッチングのDLでは攻撃はまだ無理だろうと思うけど)攻撃はAIがやったのではないかとか，

雪の影響でテレワークするぞと社長がTweetしたすぐ後に事件が起こったとか(それって内部の犯行か，テレワーク所以のなんらかの脆弱性へのアタックか?)，

話題は尽きない．

BlockChain自体の安全性の話しや，攻撃はやはり暗号鍵・アカウントへのアタックが可能性が高いとか，高額・少額でも同じ処理とか，問題提起があった．

ただ，参加者のほとんどは，おそらくBlockChainに係わる仕事をやっている訳でもなく，CoinCheckのユーザでもなく(一人見つけた．もしかしたら多いのかも)，単なる(素人の)第三者なので，突っ込んだ議論なんてできる訳もなかった．

今までのPC，サーバーサイドの情報セキュリティへの心構え，対策，対応から，スマホ，IoT，BlockChainと対象は新しくなり，さらに複雑化してきていているので，参加メンバーの平均年齢の高さと，情報セキュリティに係わる技術は作らずに，海外技術を利用して組み合わせているだけの今のプロダクト，サービス中心のビジネスに相当危機感を感じた．

おそらく，IoT, BlockChain領域の情報セキュリティは，Security by Designがベースなので，これまでのように情報セキュリティ専門家に頼むのではなく，それぞれの創る分野の人達で情報セキュリティを考えて決定することが必要になっていくのでは無いかと思う．

2017年9月23日(土)に，神戸市のしあわせの村開催のCODE for JAPAN SUMMIT 2017の「Monacaとオープンデータで作るスマホアプリワークショップ＋ハッカソン」に参加してきたので，メモ．

前提・問題提起：

・MonacaはJavascriptベースのプログラムをiOSやAndroidのアプリに変換する環境．

・サンプルの電子おみくじやゴミ分別クイズとかで準備運動

・本命は，Google Map上にGPS情報(経度,緯度)情報でプロットするアプリ

→サンプルはGPS情報をJSONに加工して読み込んだAED配置情報の表示

　※神戸市のAED情報はGPS情報が含まれる

・ハッカソンの問題提起として，自治体が公開しているオープンデータを使って何かアプリを考えてみること

　※神戸，大阪のオープンデータは使えそう

・IT素材としては，スマホアプリ開発環境とサンプル(Google Map)，自治体のオープンデータ

過程：

・3工程(Monacaハンズオン，オープンデータ・アイディアソン(作成)，発表)

・実際の開発時間は1時間半ぐらいだったので，初見の環境，ソース相手なので，難しいことができない

・自治体のオープンデータもすぐにJSON化できる訳で無い (CSVのファイルも加工が必要.一筋縄にいかない)

・アイディアと言っても，データ連係を試す時間もない

→使えそうなデータを見つけて，何らかの方法で変換して，プロットする

自主課題設定：

(本当は住んでいる街である三田市のデータを使いたかったが，適当なデータがなかったので)神戸市が出してる緊急避難所データを使って，Google Map上に，屋外，屋内避難所をプロットし，自分のの最寄り避難所がわかるようにする．

課題を進める為の作業：

・神戸市避難所データを見つける　Open Data Kobe:　https://data.city.kobe.lg.jp/

　安全・安心→避難所(CSV)

２つのcsvファイルをダウンロードする

201706-okunai-hinan.csv

201706-okugai-hinan.csv

あとは，sed, awkを駆使して，Monaca環境で使えるJSON形式のファイルを作る

手動も一部取り入れて，後，手修正もやらないといけなかった．

できたアプリがこれ．

単に，屋内，屋外避難所の位置をプロットしただけだが，割と説得力がある．

神戸市は避難所多い！

ちなみに我が三田市もオープンデータと言っていて，避難所情報も"市指定避難所の名称と電話番号（エクセル：30KB）"と電子データとしてあるのだが，座標情報がない．こんな感じで，地図にプロットは出来なさそう．

そもそも33箇所しかないのも結構心配になってくる．（これはオープンデータとは関係無い）

ちなみに，ハッカソンの例にあった，神戸市のAED設置場所情報(GPS座標付き)も，三田市では，電子データとは言っても，HTMLとして表示されている．

これも再利用は結構難しい．

オープンデータで，GPS座標まで入っているデータを公開している神戸市では，こんなことができる．

圧倒的な財力の差か，オープンデータの取組の差か...

JavascriptでスマホアプリができるMonacaも凄いけど，自治体のオープンデータの格差がここまであるとは知らなかった．

市民としては，強く行政に要望したいと思います．