1
0

組込み機器の通信セキュリティ対策は待ったなし!(その2)

Posted at

組込みソフト屋から見た証明書による認証の仕組み

前回(https://qiita.com/Cente_mw/items/fd6b331a45e86f0c3b82) は組込機器に対するセキュリティ対策が待ったなし!な状態だ、ということと、例として認証というものの大事さについてお話しました。今回は認証の中でも秘密情報が第三者に流出しない公開鍵暗号を使った仕組みについて解説します。

普段なんとなく「証明書を使ってサーバが正しいことを確認して…」とか「IoT時代はクライアント証明書が必須で」 のように会話していますが、 「結局誰が誰を正しいと確認することで、それは証明書の何を拠り所にしているのか?」 をパッと答えるのは難しいのではないでしょうか。

組込みソフトの世界でもTLS通信が一般的になり、「証明書による認証」を実装する機会も増えていると思います。外部ソフトウエアを導入するとしても、その基本的な考え方を理解しておいた方が良いです。

まず、公開鍵暗号には2つの使い道がある、という話をします。(公開鍵暗号とは何ぞやという部分はQiitaにもたくさん良い解説記事がありますのでそちらをどうぞ。)

A 送信側が公開鍵で暗号化して、受信側が秘密鍵で復号する
これは、第三者が見ているような経路で秘密情報を相手に送信する場合に使われます。つまり盗み見防止です。公開鍵で暗号化した情報は秘密鍵でしか復号できないので、仮に第三者が公開鍵を入手しても問題ありません。逆に、秘密鍵は絶対外部に漏らしてはいけません。
この仕組みはTLSでは共通鍵生成に使う乱数を相手に送る際に使われます。そんなに便利なら共通鍵暗号なんて使わずにずっと公開鍵暗号でデータも暗号化すりゃいいじゃん、と思うかもしれませんが、公開鍵暗号の計算はとっても重いのです。特に組み込み機器向けCPUを相手にしている我々から見ると、一回の公開鍵暗号の計算だけで数秒はかかるボリュームです。とてもとてもデータ通信には使えません。

それで思い出しましたが、以下余談です…

そんな知識もまだなかった若い頃、確かOpenSSLをルネサスSH7710環境に移植したときだったと思いますが、この計算の重さがハングアップの症状に見えたことを思い出します。移植は問題ないはずなのに、何度電源投入からやりなおしても同じところで機器の応答がなくなってしまう…。1時間くらいソースコードを追ったのですが原因がわからず、反応がなくなったデバッグシェル画面を目の前に腕組みをして長考に入っていると、処理完了時に表示されるよう仕込んだ「OK」の文字がぽろっと表示されたのです。ハングアップではなく単に公開鍵の計算に数十秒かかっているということにその時初めて気づいて、組み込みプログラミングの厳しさをまた一つ学んだ瞬間でした。

B 送信側が秘密鍵で暗号化して、受信側が公開鍵で復号する
これは、確かに本人が送信した内容であることを確認する場合に使われます。つまりなりすまし、改ざん、否認防止です。秘密鍵で暗号化した情報は公開鍵でしか復号できないので、自分が持っている相手の公開鍵が正しい(相手の秘密鍵とペアのものである)という前提において、相手から送られてきたデータを公開鍵で復号して得られた情報は、間違いなく相手が送信したものであると確認できます。公開鍵とペアの秘密鍵を持っている本人以外、そのデータを作ることができません。
だからこそ、このケースでも秘密鍵は絶対外部に漏らしてはいけません。

では、TLSの通信時にサーバ認証とクライアント認証が動く、とはどういうことかというと、サーバ・クライアント双方で上記「B」が走る、ということです。
クライアントの方はTLSハンドシェイクでサーバ証明書(CAの署名入り)を受け取って、別途持っているCAの公開鍵でサーバ証明書を検証(具体的には、署名をCA証明書内の公開鍵で復号した値と、自らサーバ証明書内容から計算したハッシュ値を比較。下図参照。)します。
これらが一致した、ということはサーバ証明書内容について確かであることをCAが保証している、ということです。サーバ証明書内容としてはURLのFQDN、組織名、住所、公開鍵が含まれていますので、結果的にクライアントとしては正しいサーバと通信していることを確認した上でサーバの公開鍵を得るわけです。
ここで、あらかじめクライアントに必要なのは上位CAの証明書(公開鍵)です。

image.png
図 クライアントでのサーバ証明書検証

逆にサーバの方は上記と全く同じことをすることでクライアントを認証します。デバイスの数だけクライアント証明書が存在することになるので、どう用意するのかが問題となりますが、IoT時代の現代ではクラウドのクライアント証明書発行サービスを使うケースが多くなってきているように思います。
ここで、あらかじめサーバに必要なのはクライアント証明書の署名をした上位CAの証明書(公開鍵)です。

以上が証明書を使った対象の認証(正当性確認)の仕組みです。これは組み込み開発の立場から見るとTLSだけではなくOTAで外部から受信したファームウエアが正しいことの確認や、セキュアブート時にファームウエアが正しいことの確認などにも応用されており、仕組みを理解しておくと「それを運用するにあたって考えなければいけないこと」が理解できると思います。

今日の閑話

セキュリティ関連の開発に携わっていると暗号・復号というキーワードはよく出てきますが、誤りだとわかっていてもつい「復号化」って言ってしまいます。落ち着いて考えるとわかるのですが、「暗号」とは平文から変換された結果を指す言葉で、平文を暗号に変換する行為のことを「暗号化」と言うわけです。一方「復号」は暗号文を平文に戻す行為そのものを指す言葉です。だから「化」の字は不要なんです。あえて「化」の字を使うなら、復号は「平文化」が正しいんでしょうね。

Cente:
https://www.cente.jp/

お問合せはこちら:
https://www.cente.jp/otoiawase/

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0