僕も読んでいるソフトウェアエンジニア向け月刊誌「Software Design」。最近は連載”インターネットの姿をとらえる”を愛読しています。そのSoftware Designから暗号技術・認証・認可の特集をピックアップしたものが本書になります。以前読んだことがある記事もあるかもしれませんが、記憶力はそんなに良くない（笑）実際時が経てば忘れてしまうものなので、定期的に再学習することは必要と思います。

暗号技術は現代において必須の技術、そして知れば知るほど暗号の歴史は奥が深く、近年多用されている公開鍵暗号とそれを利用したディジタル署名を考えた人は天才だと思いますね。暗号技術がなければ、インターネットを安全に利用することは不可能です。

1.今更聞けない暗号技術

暗号技術における基本、さすがにここが分からないCISSPではないです。暗号技術入門の内容も紹介されています。この本は暗号について非常に詳しく説明されており、おススメです。CISSPの勉強の一環でこの本も読んだことがあります。ところで暗号には高度な数学の計算式が活用されています。この章も数学式がたくさん掲載されています。自分は数学になると途端に頭が受け入れるのを拒否する・・・。

2.SSL/TLS入門

SSL証明書に対応していないWebサイト(ブラウザに表示されるURLがhttp://から始まる)も、僅かとなりほぼ世の中はHTTPS。しかし数年前はSSL証明書に対応するのはやや手間がかかりました。GlobalSignでSSL証明書を高いお金払って購入し、自分でCA証明書やサーバ証明書を配置して・・・とかやりましたが、Let’s Encryptのほうが簡単（最初の認証が少し面倒ですが）なのに加えて何より無料なので、金融機関のようなブランド価値が高いサイトを除いてはLet’s Encryptを使うようになった世の中です。

Let’s Encryptが有効期間6日間のサーバー証明書を導入、2025年末までに一般提供

90日の有効期限で都度更新が必要だったSSL証明書が今後は6日になるとのこと。しかし自動更新が普及した現代ではそれも大きな運用負荷とはならないでしょう。セキュリティがさらに強化される、良いことです。

僕は業務ではAWSを使うことが多いのですが、AWSでは無料のSSL証明書をCDN（CloudFront）やロードバランサー（ELB）に直接搭載できるようになっています。サーバ(EC2インスタンス)にファイルを設置する必要も、自動更新のためのスクリプトをcronで設定する必要もありません。楽です。AWSはそういう運用コストを軽減してくれるのがありがたいです。逆に言うと、この本に書かれているようなCA証明書やルート証明書による証明書チェーンというのはSSL/TLS暗号化における重要な要素なのですが、サービスによってオブラートに包まれ、良くも悪くも分からなくても使えるようになりました。

過去話題になったTLS/SSL脆弱性「HeartBleed」についてもせっかくなので勉強しました。 Heartbeat拡張は、通信相手が正常に動作しているかを確認するために使用され、通信相手に対して任意の長さのデータを送信し、同じデータが返ってくることで確認を行います。Heartbeat拡張の実装にバグがあり、送信されたデータの長さのチェックが適切に行われていませんでした。そのため、攻撃者は実際のデータよりも大きな長さを指定することで、サーバのメモリから任意のデータを読み取ることが可能になりました。つまりバッファオーバーフローが原因だったのですね。攻撃者は、Heartbeatリクエストでペイロード長を偽装し、実際のペイロードよりも大きな値を指定すると、OpenSSLは、指定された長さのメモリ領域を読み取り、応答として返し、実際のペイロードを超えたメモリ領域が読み取られる脆弱性でした。

3.今更聞けないSSH

SSL/TLSを理解した後では、公開鍵方式を利用したリモートデスクトップ＝SSH、とすんなり理解することができます。

4.今更聞けない認証・認可

この本の中では最も難しい内容になっていました。何回も読み直しました。FIDOとパスキーの違いは、FIDOは公開鍵暗号方式に基づいた認証規格なのに対して、パスキーはその具体的な実装の一つ。従来のFIDO認証では、認証に使う秘密鍵がデバイスごとに生成されていたため不便でしたが、パスキーでは、クラウド上に認証情報を保持することによりデバイス間で認証情報が安全に同期されるため、複数のデバイスで同じ認証情報を使用できる。利便性が圧倒的に向上。OAuth2.0についても過去このサイトで何回も書いているのですが、やっぱり忘れてしまうので再学習できて良かったです。

5. 挫折しないOAuth2、OpenID Connect入門

試験でお約束のOAuth2.0とOpenID Connectの違いについても説明されています。 OIDCは、認証の具体的な方法（パスワード認証、多要素認証、生体認証など）を規定していません。認証方法は、IdPが自由に選択・実装できるため、IdPは、セキュリティ要件やユーザーの利便性に応じて最適な認証方法を選択できます。OIDCは認証されたユーザーの情報をアプリケーションに安全に伝えることに重点を置いています。このあたり覚えては忘れての繰り返しです。

最後に

再学習ができて有意義でした。そして1点知識以外でも学びがありました。第4章と第5章は同じ技術を説明しています。しかし、内容の理解しやすさがかなり異なっていました。どちらが分かりやすかったかはここでは記しませんが、知っているということと、それを他者に説明するということは別であるということを実感しました。