つれづれ日記
Fedora 29カテゴリ 1/1
Fedora 29のcrypto-policiesは以前見たときよりもかなりきびしくなり、よかった。 が、FUTUREにするとAES 128が使えなくなるなど暗号鍵の最低長も制限されるらしく、LetsEncryptで作ったECC 384 bitの証明書が使えなくなっていた。AES 128は明示的に禁止指定を入れるか、TLS 1.3では有効なリストから削除されていてわかった。

$ cat /usr/share/crypto-policies/FUTURE/opensslcnf.txt
CipherString = @SECLEVEL=3:kEECDH:kEDH:kPSK:kDHEPSK:kECDHEPSK:-kRSA:-aDSS:-AES-128-GCM:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:-SHA1:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
MinProtocol = TLSv1.2

直接のECCの鍵長制限は見当たらないがSECLEVEL=3にある。 OpenSSLのSSL_CTX_set_security_levelのセキュリティレベルは0から5まで、NISTの暗号方式利用のガイドラインを参照した内容になっていて使いやすい。

レベル / 下限項目 bit長 公開鍵長 ECC鍵長 TLS その他制限
レベル0 下限なし
レベル1 80 bit 1024 bit 以上 160 bit以上 SSLv3以上 -
レベル2 112 bit 2048 bit 以上 224 bit以上 TLS 1.0以上 -
レベル3 128 bit 3072 bit 以上 256 bit以上 TLS 1.2以上 PFS必須
レベル4 192 bit 7680 bit 以上 384 bit以上 TLS 1.3以上 SHA1 MAC禁止
レベル5 256 bit 15360 bit以上 512 bit以上 ... -

いつごろからどのセキュリティレベルを適用するかは、NISTやCRYPTRECなどの暗号方式の標準化機関が例年調査と発表を行っているのでこれに従うのがよい。2018年現在は政府機関では112 bitのセキュリティレベルが必要となっている。

しかしFedora 29のcrypto-policiesのDEFAULTでは、SECLEVEL=1となっている。Fedora を使うのは政府機関ではないからか。FedoraのmirrorサーバーがSSLv3で応答する理由がここにあるようだ。

よく見るとFedora のcrypto-policiesの内容がきびしくなったのは上のほうで、デフォルト設定は問題ありということがわかった。

なお、Let's Encryptで作ったサーバー証明書が使えなくなったのはなぜか? サーバー用公開鍵はECC 384 bitで問題がないが、Let's Encryptが署名する公開鍵はRSA 2048 bitで基準未満だった。

LetsEncryptでRSA 4K鍵対応してほしいけどRSA 鍵長による性能問題は重い (2018-03) という記事があり、これはぎりぎりにならないとRSAの鍵長は増えないな、と。そういう意味でも証明書を発行するCA側がECCを使えるようにするのは重要だ。

ただし現行のRSAもある程度維持する必要があり、異なる公開鍵暗号方式を使った証明書を どのように発行するか問題がある。1つの証明書にRSAも含めるのか、RSAとECCの暗号方式ごとに証明書や証明書発行機関を分けるのか、政府によって脆弱な暗号方式を標準化していたNISTのECCを使うのか、ではsecp, edなどどのECC方式を採用するのか、などなど。

DNSSECの場合は、すべて暗号方式ごとに公開鍵を別々にリソースレコード名をつけて配布し、クエリでもキャッシュでも暗号方式をだれもが選べるようになっている。DNSSECでは「1つのファイルかオブジェクトに複数の暗号方式で作ったデータをまとめて配布」することは、ない。まとめて配布するときはZIPかtar, rsyncなど別のツールを使うものだろう。これからの量子コンピューターの時代には、暗号方式の寿命もある。

あと、SSL_CTX_set_security_levelの資料にはハッシュ関数について触れていない。

Fedora 29カテゴリ 1/1