組み込み機器のTLS実装
IoT機器の安全な通信にはTLSが欠かせません。しかし、組み込み機器はメモリやCPUなどのリソースが限られるため、実装には工夫が必要です。この記事では、TLSの基本やMQTT・BLEとの関係、証明書運用、リソース制約下での実装ポイントを解説します。なお、現場では慣習的にSSLと呼ばれることがありますが、現在主流はTLSです。
TLSとは
Transport Layer Security（TLS）は通信の暗号化と認証を担う安全な通信プロトコルです。TLSは暗号化やなりすまし防止など、セキュリティに不可欠な機能を複数同時に実現できるため、常時ネットワークに接続している環境では必須の仕組みです。
TLSの認証は公開鍵暗号方式に基づいています。証明書（公開鍵）を使って相手を認証し、通信データ自体は確立した共通鍵（セッション鍵）で暗号化します。TLS通信を担当するサーバは、クライアントに提示するための証明書を事前に登録しておく必要があります。不特定多数がアクセスするWebシステムでは証明書が必要なのはサーバのみであることが多いですが、IoT機器においてはクライアント側のなりすましによるリスクも存在します。
クライアント側も証明書を登録し、サーバと相互認証することでより安全な通信を実現します。ただし証明書の配布・更新・失効運用が必要になるため、なりすましリスクや運用体制に応じて採否を判断します。
MQTTとの関係
MQTTは軽量なPublish・Subscribe型のプロトコルです。センサ情報の収集や遠隔監視に使われています。MQTT仕様そのものに暗号化は含まれないため、暗号化・サーバ認証はTLS（MQTTS）で実現するのが一般的です。
インターネット上など安全が保証されないネットワークを介して通信する場合はMQTT over TLSの形式で利用します。
証明書を用いてBroker（ブローカー）を認証できます。Publisher（パブリッシャー）側にもクライアント証明書を導入して相互認証にすれば、双方のなりすましを検知できます。
MQTT over TLSは通信を暗号化するため、通信途中で傍受しようとする盗聴攻撃からデータを守れます。Subscriber（サブスクライバー）とBrokerの間の通信も暗号化され、BrokerからSubscriberへの配信データを改ざんする攻撃も防げます。
BLEとの関係
BLE（Bluetooth Low Energy）は消費電力が低く、低帯域で通信できる方式です。センサとゲートウェイの間など近距離の通信に向いています。ペアリングの際にデバイス間で鍵を交換するため、適切なペアリング方式（LE Secure Connections を使用した Passkey Entry など）を選び、暗号化が有効になっていることを確認できれば、近距離区間の盗聴リスクを軽減できます。
しかしゲートウェイ経由でクラウドへ中継する場合など、インターネットを介する区間ではTLSとの併用が推奨されます。
BLE区間はBLEのリンク層暗号で保護し、ゲートウェイでIPネットワークへ中継する場合は、その区間をTLSで保護する構成が一般的です。MQTTとも組み合わせて、BLE、MQTT、TLSを前提とした通信環境を作ることで、エッジからクラウドまでIoT機器周りのセキュリティを一貫して確保できます。
通信をセキュアにする証明書
TLSの通信上、クライアントの証明書は任意ですが、IoT機器はデバイス自体の偽装を防ぐためクライアント証明書まで導入します。サーバであれば数台ですみますが、量産のデバイスになれば相当な台数の証明書が必要です。
デバイス1台ごとに別々の証明書が必要なため、実際はキッティング時など、製造工程の一部に証明書の発行や登録作業が組み込まれています。また証明書には有効期限が設定されており、証明書の有効期限検証には時刻が必要です。RTCの搭載や、起動時にTLSでサーバへ接続して、署名付きの時刻情報を取得するなどの安全な時刻同期を使用し、自局の信頼性も含めて設計します。
紛失・盗難・鍵漏えいなどが疑われる場合は、証明書を失効または無効化し、サーバ側で接続を拒否できる運用が必要です。ただし、ネットワーク条件によっては失効・無効化の処理が難しいため、短寿命証明書やサーバ側の拒否リストを使用するなど、運用に合う方式を選びます。デバイス台数が増えれば増えるほど運用の手間がかかります。
TLSレベルのクライアント認証のかわりに、アプリケーション層でトークンなどを用いたクライアント認証する仕組みを持つサービスもあるため、設計時から検討に入れておくと便利です。
リソース制約下でのTLS実装
リソースが限られる組み込み機器上でTLSを実装する際の注意点を記載します。
メモリ使用量の節約
TLS通信はハンドシェイクを経て通信するため、MQTT単体で通信した場合よりもオーバーヘッドが増えます。証明書自体の格納や、ライブラリの実行によってもメモリを消費するため、限られたメモリで動作が求められる組み込み機器では負担になりかねません。
軽量なTLSライブラリを使ったり、セッション再開の仕組みを導入したりして、リソースを節約しながら実装する必要があります。
セキュリティ担保とリソース制限のバランス
セキュリティに必要な機能を実装するほど、メモリ使用量が増加しかねないため、使用リソースとセキュリティの両立を考慮する必要があります。
たとえばTLS 1.3はTLS 1.2よりハンドシェイクの往復を減らせるため、接続確立の遅延や通信オーバーヘッドの低減が期待できます。メモリ使用量はライブラリ構成に依存するため、要件に合わせて機能を絞り込みます。
通信方式とリソースの両面から要件を見直すことで、組み込み機器に必要かつセキュアな通信を実現できます。
