特集:IoTがもたらす製造業の革新〜進化する製品、サービス、工場のかたち〜

組み込み技術者向けTLS1.3基礎解説(後編):IoTでTLS1.3を活用すべき3つの理由IoTセキュリティ基礎解説(3/3 ページ)

» 2018年10月10日 10時00分 公開
前のページへ 1|2|3       

5.0-RTTのセッション再開が可能に

 前編では、TLS1.2のセッション再開シーケンスとしてセッションIDを保持する方式を紹介した。この方式は、セッション再開を継続する間は同じセッションIDとmaster_secretを使用するため、サーバにキャッシュしたmaster_secretが漏えいすると、セッション開始までさかのぼって暗号を解読されるリスクがある。また、この方式は大量のセッション情報をキャッシュする必要がある場合にサーバへの負担も大きい。

 そこで、より安全で効率的な方法としてセッションチケットを使用する方式が考案された。この方式では、セッション開始時にサーバが再接続用のチケットを発行し、NewSessionTicketメッセージでクライアントに送付する。セッションチケットは鍵やパラメータが確定した後に発行し、master_secretも含めセッション再開に必要なパラメータを全て暗号化して格納する。セッション再開時はクライアントがセッションチケットをそのままの状態でサーバに返すため、サーバはこれを復号することでセッションの情報を復帰することができる。つまりセッション情報をキャッシュしておく必要がない。

 ただ、この方式では毎回セッションチケットの復号処理が必要なため、セッションID方式の再開に比べると性能は劣化してしまう。その代わりにTLS1.3では、PSK(Pre Shared Key:事前共有鍵)ハンドシェイクと統合することでセッション再開の手続きを効率化し、0-RTTでセッションを再開できるようになった。PSKは名前の通り、セッション再開用の鍵を事前に生成しクライアントとサーバで共有しておくことを意味する。図3に示したが、PSKもセッションチケット発行と同様にハンドシェイク後のタイミングで生成/共有される。事前共有なので、次回接続時はPSKを元に鍵生成し直ちに暗号化が可能になる。

図3 図3 TLS1.3のセッション再開例(0-RTT)(クリックで拡大)

 TLS1.3のセッション再開のシーケンス例を図3に記載してある。クライアントは、ClientHelloでセッションチケットを送信すると直後からアプリケーションデータも暗号化して送信することができる(0-RTT)。サーバは、ClientHelloで受け取ったセッションチケットを復号しセッション情報を復帰する。ServerHelloを返せば鍵共有プロセスを実行できるので、共有した共通鍵で暗号化したアプリケーションデータを送信できるようになる。PSKは認証の役割も果たすため証明書の送信も不要だ。クライアントは、EndOfEarlyDataを送信することで(PSKで暗号化された)0-RTTのデータが終ったことを知らせ、以後は共有された鍵によってアプリケーションデータを暗号化する。

 0-RTTによるセッション再開は接続の効率化を狙ったものだが、最初のアプリケーションデータをPSK由来の暗号鍵で暗号化するため、前方秘匿性がない。またクライアントの送信したメッセージを第三者が盗聴、保存し、再びサーバに送り付けて認証を試みるリプレイ攻撃に対しても脆弱である点が指摘されている。これについては、IETFが公開しているRFC 8446の「8.0-RTT and Anti-Replay」に幾つかの対策が記載されているので実装する場合に注意する必要がある。

6.IoT機器でも使うべきか

 TLS1.3は、ドラフト(試案)の段階から実装が進んでいたこともあり、2018年8月にRFC 8446として正式リリースされた時点で幾つものブラウザやライブラリで対応済みとのアナウンスが出ている。大手サイトでも今後の導入計画が盛んに発表されているので、Webを中心に急速に普及していく見通しだ。本解説記事では、TLS1.3の変更点について概要を紹介したが、全体を俯瞰した筆者の感想として「IoT機器でTLS1.3を使うべき理由」を次のように考えている。

  1. 過去の危殆化や脆弱性を払拭し、より安全でシンプルな暗号へ移行している
  2. 無線や低速通信などIoT用途での性能も意識しプロトコルを改善している
  3. 個別の変更には経緯や目的、長所、短所があり、選択肢も用意されている

 1つ目の安全面については、過去のTLSバージョンにおいても重視されてきたが、複雑さや性能劣化が課題だった。普及はこれからだが、今後はChaCha20-Poly1305やEdDSAのようにシンプルかつ性能や信頼性が高い暗号が活用されるようになるのではないだろうか。これによってハードウェアコストをかけられないような機器でも暗号活用の可能性が拡がるかもしれない。

 2つ目の性能面では、プロトコル上の配慮がなされていることも大きな特徴といえる。特に、1-RTT、0-RTTの採用はモバイルネットワークのような遅延の大きい通信における恩恵は大きく、必ずしも常時ブロードバンドに接続されているわけではないIoT機器との親和性も高い。周期的に同一サーバへの接続を繰り返すような機器にとってもセッション再開の効率化は福音だ。

 ただし、記事中でも述べたが、個々の技術には性能劣化要因となり得る変更もあり、TLS1.3を使えば必ず性能が向上するというわけではない。安全性と性能は、多くの場合トレードオフの関係にあり、最適なバランスを考慮する必要があることは原則として押さえておきたい。

 昨今、IoT機器のセキュリティ強化や通信の暗号化の必要性が叫ばれて久しいが、IoT機器は、通信の目的や頻度、扱う情報の質と量、重要性は千差万別である。常時接続のブロードバンドで、クラウドと個人情報の通信を繰り返す情報家電と、少量のセンサーデータを収集し一定間隔でサーバに低速アップロードするFA機器では、求められる性能やセキュリティ強度の要件が全く異なることは容易に想像できる。構成するハードウェアやプロセッサ、OSなども多様で、通信や暗号化に割くことができるリソースも限られるケースが多い。

 IoTの通信はプライバシーや企業秘密に関わる情報を扱うことも多く、暗号化は喫緊の課題だが、その解決のためには個別の現場で複雑な連立方程式を解く必要があり、場合によってはSSL/TLSが最適解ではないこともある。だからこそ、3つ目の理由である、個別の暗号技術の本質や実装における選択肢があることを理解しておく意味は大きい。



 SSL/TLSは、セキュリティ要件の一部であり万能薬ではないが、正しい知識と設計のもとで活用すれば、得られるメリットは非常に大きい。暗号化は、情報を経路に依存せずに効率的に運ぶことを可能にするし、何より世界中のあらゆる機器が同じプロトコルで自由かつ安全につながることのインパクトは計り知れない。SSL/TLSの正しい知識と活用が広がれば、IoT社会はますます発展していくことだろう。

プロフィール

photo

市原 創(いちはら はじめ)

国内電機メーカーで流通、金融等業務システムの基盤ソフトウェア開発や性能改善に携わり、その後キヤノングループでキヤノン製品の通信制御ソフトウェアの開発に従事。現在はキヤノンITソリューションズに勤務し、組み込みソフトウェアのセキュリティや暗号技術を中心に活動中

キヤノンITソリューションズ 組込みセキュリティ
https://www.canon-its.co.jp/products/embedded_security/

前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.