セキュアなIoTデバイス通信をやってみた(概念理解編)

はじめに

2019年5月にIoTLTにてLTをさせていただきました。
その内容のフォローを記入しながら自分なりに整理していきたいと思います。

発表内容：
スタートアップIoTデバイスのセキュリティを考える

前回までのあらすじ

セキュアなIoTデバイス通信をやってみた(現状把握編)にて、主要IoTクラウドベンダーのデバイス認証方法の傾向と、セキュリティ向上のための証明書認証を支援するハードウェアの利用を推進しているところをまとめました。

セキュリティを向上する仕掛け

大まかに内蔵型と、外付け型がある。
内蔵型の例：
TrustZone
Armのプロセッサの内部に構成される、ユーザー領域（ここではRich OSといっている）とは隔離されたTrusted execution environment(TEE)という環境で、Global Platform TEE APIを通じてのみ操作される安全な領域、とのことである。
ユーザーはここに、秘匿したい鍵情報、ユーザーに開放したくないサービスログ情報など
処理を行わせることができる仕掛けを組みこむことができる。

最近はだんだんとTrustZoneを搭載するチップが出そろってきているが、パブリックな事例はまだまだ少ないと感じる。

外付け型の例：
いわゆるセキュアエレメントや、TPM(Trusted Platform module)と呼ばれているもの。
プロセッサ外部に付き、証明書の処理を行う専用チップ。

セキュアエレメントは証明書の保存、署名、検証、暗号化、ハッシュ化などを支援する。

主なセキュアエレメントとスペック

■セキュアエレメント比較　1個で買う場合の金額
MAXQ1061　897円
 
Infineon OPTIGA™ Trust X　250円くらい

NXP A71CH　350円くらい
 
Microchip ATECC608　91円

■主な共通スペック
証明書の格納できる容量　32KB、8KB、1KBなど
署名方式：ECDSA (FIPS 186-4)
鍵交換：EC Diffie-Hellman (TLS)
乱数生成器、カウンター
AES暗号化エンジン
SHAハッシュ作成

IoTデバイスのクラウドとの通信の分析

TLSハンドシェイクという認証、暗号化を経て通信が確立される。
下記はTLS1.2のハンドシェイク例。

クライアント（IoTデバイス）側からClientHelloを送信、サーバー（クラウド）側からServerHelloの返答があり、暗号通信へ移行するというのが大まかな流れ。

■ECDSA（楕円曲線署名アルゴリズム）
セキュアエレメントのほとんどが対応している署名アルゴリズム方式。
互いに「署名」と「検証」を行い、正しい相手を認証する仕組み
ハンドシェイク内では下記が該当する。

■ECDH（楕円曲線DH鍵共有）
これもまたセキュアエレメントのほとんどが対応している鍵共有方式。
簡単に言うと双方だけが解読できる暗号化のタネとなる共通鍵を共有する仕組み

共通鍵のクライアント側とサーバー側での共有方法

互いに公開鍵を送りあい、手元の秘密鍵と相手の公開鍵で計算を行い、正しい相手からの公開鍵であれば、双方の計算結果が同じになることを利用する。

IoTデバイスのセキュリティ強化ポイント

■鍵の安全な取り扱い＝秘密鍵の漏洩を防ぐことが重要
署名アルゴリズム：秘密鍵の盗難によるなりすましを防ぐ
鍵共有：秘密鍵の盗難による共通鍵の解読、暗号解読を防ぐ

ファームにハードコードせず、秘密鍵を完全に隠す仕組みをセキュアエレメントが提供することでIoTデバイスのセキュリティを向上させる。