本記事はソラコムが提供する「SORACOM公式ブログ」に掲載された「IoT機器のTLS通信で立ちはだかる証明書の運用」を再編集したものです。
目次
IoT通信のセキュリティ、3つの要件とTLSの関係性誤った接続先へのデータのアップロードを防ぐ（サーバ認証）
サーバ認証に求められる運用要件
SORACOM を使ったサーバ認証
IoT機器のなりすましを防ぐ（クライアント認証）
クライアント認証に求められる運用要件
SORACOM を使ったクライアント認証
IoT機器のプロビジョニング
さいごに
こんにちは。ソリューションアーキテクトの渡邊です。
IoTでTLSを使った通信を行う場合によく「運用が大変」と言われます。デジサート・ジャパンのレポート「2021年 PKI自動化に関する現状調査」によると、標準的な企業では現在、50,000 以上の証明書を管理しているとのことです。通信をセキュアにしたいだけなのに、どうしてこのような運用の手間が増えてしまうのでしょうか。
IoTの「つなぐ」を簡単にするサービスを提供している SORACOM では、IoT向けの通信をより簡単にセキュアにするためのアプリケーションサービスも提供しています。
そこで本ブログでは、IoT機器でTLS通信を行う際に求められる「運用の手間」を明らかにし、SORACOM のアプリケーションサービスを使った場合の「簡単さ」について改めてご紹介できればと思います。
なお、TLS通信のそもそもの仕組みや手順については、本ブログでは解説しません。既に多くのサイトでTLS通信の仕組みが解説されていますので、そちらをご覧ください。
IoT通信のセキュリティ、3つの要件とTLSの関係性
一般的に、IoT導入の一番の課題はセキュリティと言われています。一言でセキュリティと言っても様々な脅威への対策が必要となりますが、IoT機器へTLS通信を導入する場合、どういった脅威への対策が実現できるのでしょうか。
- データの盗聴・改ざんを防ぐ
- 誤った接続先へのデータのアップロードを防ぐ
- IoT機器のなりすましを防ぐ
導入を検討しはじめた当初はおそらく、１についての対策が最も多いのではないでしょうか。ですが実はこれ、TLS通信による暗号化で無くとも、他の方法で対策できます。あらかじめサーバーとクライアントでデータの「並び替えルール」をこっそり決めておいて、データを送受信する際にその方法に沿って並び替えたりもとに戻したりすればいいのです。こうすることでルールを知らない第三者からは、データの中身を盗聴したり（ルールを知らないと読めない）、改ざんしたり（もとに戻すと意味のないデータになる）することができなくなります。これがいわゆる共通鍵暗号方式の考え方です。
それでは、２と３はどうでしょうか。１と同じような簡単な方法で対策できないものでしょうか。
誤った接続先へのデータのアップロードを防ぐ（サーバ認証）
昨今、スマートフォンやECの普及によりインターネットの通信はHTTPS（SSL/TLS）が主流となってきました。また数年前から主要なブラウザベンダーがHTTPS化を推進したことで、通常のブラウジングや動画再生であってもHTTPSが使われており、すっかり身近なものになってきたのではないでしょうか。例えばECサイトを利用するとき、「間違った（偽の）サイトじゃないよね？」とURLを確認したり、アドレスバーに警告が出てドキッとしてアクセスするのをやめたりされた経験もあるのではないでしょうか。
IoTの場合、貴重な生産設備から得られたセンサーデータや特定の個人や肖像が入ったカメラのデータが誤ったサーバへアップロードされてしまったらどうでしょう。大変なトラブルになることは容易に想像が付きます。では、皆さんがECサイトが正しいことを確認したり、ブラウザの警告画面を見て警戒したりする行為は、IoTでは誰が担っているのでしょうか。モノのInternet接続を実現するには、そういった処理をあらかじめIoT機器で実装しておく必要があります。
サーバ認証に求められる運用要件
ここではサーバ認証の仕組み自体の説明は割愛しますが、IoT機器が接続先のサーバを認証する場合は、サーバから送られてきたサーバ証明書に対して以下のようなチェックをIoT機器自身で行います。
a．接続先やフォーマットなど正しい形式の証明書か
b．適切に署名されたサーバ証明書か
c．有効な証明書か
このうちbについては、最終的にルート認証局から署名されたサーバ証明書である必要がありますが、このルート認証局自身もまたルート認証局自身の証明書（ルート証明書）を発行しており、IoT機器はbを実施するためにはあらかじめルート認証局の証明書を端末内に保持しておく必要があります。
PCの場合でも同様です。
また、「c 有効な証明書か」については、証明書には発行日と有効期限が設定されており、すべての証明書の有効期限がIoT機器のシステム時刻と照らして有効期限以内であることを確認する必要があります。それをするためにはIoT機器で時刻を管理する必要が出てきます。
これらが「証明書の運用」に求められる要件になってきます。
ルート証明書のインストールについて、LinuxやOSを持つ端末であればあらかじめディストリビューターによって保存されているので気にすることは少ない（と言っても有効期限の対応などは必要）ですが、Arduino や センサーキットなどのOSレスのデバイスを使う場合には一気にハードルが上がります。開発時に１台ずつ接続確認する分には手作業でできてしまいますが、量産となるとどうでしょう。生産プロセスでキッティングの中に組み込む必要が出てきます。また、時刻の管理についてもOSレスのデバイスの場合は悩ましいです。証明書の有効期限を確認するためだけに、NTPサーバをたててNTPを実装したり、時刻同期の仕組みを入れたりするのはとても大変ですよね。
このようにTLSのサーバ認証を行うIoTシステムでは、IoT機器へのルート証明書の事前インストールやシステム時刻の管理が求められ、さらに運用時には、時刻の同期や証明書の有効期限の管理が求められます。
SORACOM を使ったサーバ認証
SORACOM のアプリケーションサービスを使った場合はどうでしょうか。
SORACOM Beam では、デバイスから受け取ったデータのプロトコルを変換し、クラウドやお客様のサーバーに転送する機能を提供しています。SORACOM Beam のエンドポイント設定画面では以下のような表示が見えます。ここで転送先のホスト名などを設定しますが、この転送先で指定した宛先のサーバ認証は、他に何も設定することもなく SORACOM が勝手にやってくれています。ルート証明書の検証や時刻の検証も含めてすべてです。簡単ですね。
また、SORACOM Funk, Funnel では、各クラウドサービスで用意された Endpoint へ API を使ってアクセスを行います。各クラウドサービスのEndpointはHTTPSとして提供されることが一般的ですので、SORACOM が HTTPS 接続（TLS接続）をIoT機器に替わって勝手にやってくれています。
IoT機器のなりすましを防ぐ（クライアント認証）
TLSでは、サーバ認証だけでなくクライアントの認証も行うことが可能です（TLSの規格ではオプション）。サーバ認証とクライアント認証を両方行うことを「相互認証」と言ったり「mutual TLS（mTLS）」と言ったりしますね。普段、Web ブラウジングではあまり馴染みがないかもしれませんが、IoT ではむしろこちらのクライアント認証の方が重要です。
IoTでは、データを元に業務を自動化したり、データを元に重要な意思決定を行ったり、業務のデジタルトランスフォーメーションにデータを活用します。そのデータの取得元がなりすましによって偽装されていたらどのような影響が出るでしょうか。サーバ認証でお話した誤った接続先へのデータのアップロードに比べても、誤った意思決定などに繋がるより大きな影響を与える可能性が考えられます。
クライアント認証に求められる運用要件
クライアント認証の考え方はサーバ認証と同じです。しかし、サーバが１つの機器であったのに対しクライアントは複数ありますので、証明書の運用にはさらなる手間がかかることが想像できると思います。IoT機器向けのクライアント証明書発行サービスを提供している企業もありますが、クラウドサービス・プロバイダーもクライアント証明書の発行を行っていますので、ここではAWS IoTの例を見てみましょう。
このようにして作成されたクライアントの証明書は、生産プロセスの過程で１対１に対応する個々のデバイスに確実に保存しておく必要があります。生産プロセスでは、製造番号やモデル番号を外部へ印刷したりシールを貼ることはあると思いますが、個別にソフトウェアをインストールするのはとても大変な作業です。
また、クライアント証明書の真正性をクライアント自身が証明するためには、証明書の「秘密鍵」も合わせてデバイスに保持する必要があります。秘密鍵はその性質上、他者から読み取られてはまずいので、「書き込みできるが、読み出しできない領域」に保存されることが望まれます。（セキュアエレメントなど）
ではデバイスが故障したときはどうでしょう。それまで使われていた機器（故障した機器）に対応するクライアント証明書は、サーバ側で失効させる必要があります。機器が壊れたからといって、その機器のクライアント証明書が悪意ある第三者に渡ってしまってはなりすましを許容してしまいます。また、新たに交換された機器が保持するクライアント証明書は、故障した機器のクライアント証明書と同等のアクセス権などを設定する必要があります。
これらが「証明書の運用」に求められる要件になってきます。
このようにクライアント認証の運用にはデバイスも絡んでくるため、デバイスの製造時や故障による交換作業時、または証明書の有効期限管理など、機器のライフサイクルと連動した適切な証明書の運用が求められます。
SORACOM を使ったクライアント認証
SORACOM のアプリケーションサービスを使った場合はどうでしょうか。
SORACOM Beam では、グループ毎、SIM毎それぞれでクライアント認証を使うことができるようになっています。IoT機器を特定の役割（ロール）でグルーピングして認証する場合にはグループ毎の設定でも十分ですが、ここではせっかくなのでSIM毎のクライアント認証を見てみたいと思います。SIM毎のクライアント認証は「multi credentials per group」という機能（現時点ではMQTTのみ対応）を使います。
以下の「Beam の multi credentials per group 機能を設定する」画面では、認証情報欄にプレースホルダー（#{imsi} や #{imei} ）を用いた設定例が記載されています。これがSIM毎に使われる認証情報IDを指定する方法で、転送先にデータを送る際には、#{imsi} 部分が実際のIMSIへ置き換わって認証情報の識別を行います。
また、SIM毎の認証情報は、以下の認証情報ストアにてクライアント証明書（X.509 証明書）として事前に登録することが可能となっています。なお、認証情報ストアに登録できるキーの個数の上限は 100 個までの上限がありますのでご注意ください。
このように、SORACOM ではデバイスの認証にSIMを活用できるため、認証情報の管理をデバイスから切り離すことが可能となります。それによって、現場での作業から解放され、生産プロセスでの対応や故障時の対応などはリモートから可能となり、運用の手間を軽減することができます。
IoT機器のプロビジョニング
これまでの流れで、SORACOM を使ったサーバ認証、クライアント認証の流れを見て頂きました。それでもクライアント認証については、事前にデバイス毎の証明書を準備したり、認証情報ストアへ登録したりと、IoT機器を使い始めるまでの手順（プロビジョニング）には手間が多いです。これはIoT機器を個別に認証しようとした場合には仕方のないことですが、このプロビジョニングの手間を少しでも軽減するサービスもご用意しています。
SORACOM Krypton を利用すると、デバイスを自動的にプロビジョニングし、デバイス証明書を発行して、AWS IoT に登録するまでを自動化することできます。あらかじめデバイス証明書をデバイスごとに登録する必要はありません。デバイスを起動する際に初期設定としてプロビジョニングを実行することで、デバイス証明書を使ったセキュアな通信が可能となります。ここでは詳細な手順については割愛させていただきますが、プロビジョニングを検討される際にはこちらもご参考ください。
また、SORACOM Krypton では、API を使用する際にアプリケーションの認証に用いられる Token の生成もできますので、アプリケーション開発者の方へもご参考になれば幸いです。
さいごに
最後まで読んでいただき、有難う御座いました！
今年もSORACOM Discoveryの開催がいよいよ近くなってきました。今年は、7/6 ~ 7/7でオンライン開催されます！皆さまのご参加お待ちしております！
投稿 IoT機器のTLS通信で立ちはだかる証明書の運用 は SORACOM公式ブログ に最初に表示されました。
この連載の記事
-
第484回
デジタル
AWS re:Invent 2024に見る、IoTの成熟と生成AIとの融合 -
第483回
デジタル
二歳半の子供を持つエンジニアの一日の働き方 -
第482回
デジタル
VPN 対応の産業用 LTE ルーターの価格改定【30%オフ】 -
第481回
デジタル
時間帯に応じたメール通知の構築方法 : SORACOM LTE-M Button と SORACOM Flux の活用 -
第480回
デジタル
SORACOM Flux 料金プランを発表しました -
第479回
デジタル
12/11-13 商業施設・店舗DX展に出展：最新IoTソリューションや事例をご紹介 -
第478回
デジタル
コープさっぽろが、クラウド型カメラ「ソラカメ」を全店舗で導入、現場主導の改善を実現、サーバールームの異常な温度上昇を通知する新規掲載レシピ takuyaのほぼ週刊ソラコム 11/16-11/29 -
第476回
デジタル
WebRTCとMedia over QUIC Transportの性能比較 -
第475回
デジタル
SORACOM Lagoon 3 の [Math] 機能で、複数データを組み合わせた通知の手順 -
第474回
デジタル
SORACOM Flux の AI アクションに Amazon Bedrock – Anthropic Claude 3.5 Haiku を追加、Teltonika RUT240 の価格を改訂 takuyaのほぼ週刊ソラコム 11/02-11/15