米ユタのDigiCertとは無関係なマレーシアのDigicert Sdn認証局の問題について見てみたぞ(補足1)

昨日書いたマレーシアのDigicert Sdn認証局の記事で ちょっと補足しておこうと思います。

CRLについて

• Digicert Sdnの問題を指摘された2つの中間CAは、 発行した証明書にCRL配布点(CDP)拡張は無いんだけども、 CRL自体はきちんと3日おきに発行しているようです。
• Entrustは、 Digicert Sdnの中間CAを少し移行までの猶予期間を持たせ 11月8日かそれより前に失効させると声明しています。 現時点(11月7日18:50 JST)では失効されていません。
• GTE CyberTrust Global Root(Verizon)は 失効させるといった声明はありません。 現時点(11月7日18:50 JST)では失効されていません。

CRLの発行周期および最新のCRLの発行日の情報は以下の通りです。

認証局名	発行周期	thisUpdate	nextUpdate
Entrust.net CA 2048 ルート認証局	7日	2011年11月6日	2011年11月13日
Digisign Server ID - (Enrich) (Entrust用)中間認証局	3日	2011年11月6日	2011年11月8日
GTE CyberTrust Global Root ルート認証局	3ヶ月	2011年11月1日	2012年2月4日
Digisign Server ID (Enrich) (GTE用)中間認証局	3日	2011年11月6日	2011年11月8日

Mozilla(FireFox)の認証局ブラックリスト追加のソースコードの更新

Mozillaでは前回のDigiNotarの証明書をブラックリストに入れる際、 certdata.txt に証明書を登録し、これからコード certdata.c を自動生成しています。

http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt

このファイルの最終更新は2011年11月3日ですが、まだDigicert Sdnに 対応はしていないようです。

以上、ちょっと補足でした。アップデートがあれば、また書きます。

関連記事

• 2011.11.06 米ユタのDigiCertとは無関係なマレーシアのDigicert Sdn認証局の問題について見てみたぞ

米ユタのDigiCertとは無関係なマレーシアのDigicert Sdn認証局の問題について見てみたぞ

2011年11月3日のニュース でマレーシアのDigicert Sdn. Bhd.社という認証局が問題のある証明書を発行しており

• 現在、解読が可能とされている512bitのRSA鍵の証明書を発行している
• SSLサーバー証明書として使うには証明書の拡張領域に問題があった
• マレーシア政府機関に発行したものにも512bitの弱い鍵が使われている
• 発行した22枚の証明書で512bit鍵が使われている

そのような運用が問題視され、

• MicrosoftやMozillaが問題のあったマレーシアのDigicert Sdnの中間証明書を ブラックリストに入れた。FireFoxでは8からの対応になる。
• Digicert Sdnの上位のルート認証局であるEntrust社は問題のある中間証明書を、少し移行までの猶予を持たせ11月8日かそれより前に失効させる

という対応を取りました。

最初、ツイッターなどでこの問題が紹介されたとき米ユタ州にある割と 有名な認証局Digicertの子会社が問題が起こしたのかと 勘違いされていたようですが、全く別のマレーシアの会社だったようで 米DigiCert社も声明を出しています。 米DigiCert社は先日のオランダのDigiNotar社の時も 名前が似てたため「うちは関係ないよ」と声明だしており、最近踏んだり蹴ったりですねw。 さて、今日はこのマレーシアのDigicert Sdn認証局について、 ちょっと見てみたので報告したいと思います。

マレーシアDigicert Sdn社の幾つかの認証局

マレーシアのDigicert Sdn社はルート、中間を含め(おそらく)13もの認証局を持っています。我々に危険性の影響があるのは図の左側、多くのブラウザに信頼するルート認証局として搭載されている EntrustとGTE CyberTrust(現Verizon)をルート認証局とする 2つの中間認証局です。

Digicert社のそれぞれの認証局の特徴などを下表にまとめてみました。

認証局	特徴
ルート認証局
Digicert Class2 Root	組織、個人(18歳以上)向けに発行する下位CAを持つ信頼レベル高中のルート認証局
Digicert Class1 Root	個人向けに発行する下位CAを持つ信頼レベル低のルート認証局
Malaysia Primier CA 1024	SHA1withRSA 1024bit 大量にMD5withRSAユーザ証明書を発行
他社ルートの中間認証局
Digisign Server ID (Enrich)	上位CAはGTE CyberTrust Global Root 自己署名証明書は公開してなさそう SSLサーバー証明書と(証明書管理者用?)ユーザ証明書を発行
Digisign Server ID - (Enrich)	上位CAはEntrust.net Certification Authority (2048) 自己署名証明書は公開してる SSLサーバー証明書と(証明書管理者用?)ユーザ証明書を発行 上のとは " - "(ハイフン)が違う
Digicert Class2 Root下位の中間認証局
Digisign Server ID	SHA1withRSA 1024bit 証明書管理者用のユーザ証明書を発行しているようだ 金融系やカード系が多い
Digisign ID (Enhanced)	S/MIMEにも使えそうなユーザ証明書を発行 変なプライベート拡張がある
Digisign ID (Basic)	一般のユーザ証明書を発行しているようだ
MyKAD Online	一般のユーザ証明書を発行しているようだ
DIGISIGN iVEST CA	ユーザ証明書かS/MIME証明書か？
DIGISIGN iVEST CA Enhanced	ユーザ証明書かS/MIME証明書か？
Digicert Class1 Root下位の中間認証局
DigiSign ID	現在でも大量のRSA 512bit鍵のユーザ証明書を発行しているようだ
Digisign Corporate Email	本中間CA証明書は2006年に期限切れ 下にユーザ証明書は見当たらず

これらのすべての認証局証明書の鍵長は 1024bitか2048bitで証明書プロファイルも 特に問題になりそうな点は見つかりませんでした。 他にも

• CIMB Investment Bank Berhad Enterprise CA
• Bank Negara Malaysia Sub CA

などマレーシアの銀行の認証局を運用しているようですが、 証明書が見つからず調査できませんでした。

EntrustとGTE CyberTrustルートのDigicert Sdn中間認証局

マレーシアのDigicert Sdnのルート証明書はIEやFireFoxなどの ルート証明書には搭載されておらず、 今回、Microsoft や Mozillaがブラックリストに入れたのは EntrustやGTE CyberTrustをルート認証局とするDigicert Sdnの 中間CA証明書です。 IEでみるとGTE CyberTrustルートの場合、証明書チェーンはこんな感じ、

IEでみるとEntrustルートの場合、証明書チェーンはこんな感じです。

両者を少し数字で比較してみましょう。

比較項目	GTE CyberTrustルート	Entrustルート
(a) 証明書発行枚数(2011年11月5日時点、延べ)	1198枚	984枚
(b) (a)のうち2011年11月3日時点で有効なもの	110枚	448枚
(c) (a)のうち2011年11月3日時点で有効なマレーシア政府のもの	69枚	205枚
(d) (a)のうちRSA512bit鍵のもの	37枚	8枚
(e) (a)のうちRSA512bit鍵で現時点(11/5)で有効なもの	7枚	7枚
(f) (a)のうちRSA512bit鍵で現時点(11/5)で有効なマレーシア政府ドメインのもの	0枚	5枚

ニュースで取り上げられている22枚という数字は どこから出てきたものなのかよくわかりませんね。

現在、解読された実績のある512bit RSA鍵の証明書を発行している ことは問題といえば問題ですが、利用者が鍵を生成して 証明書発行要求しているわけですから利用者側にも問題がありますよね。

問題のある証明書拡張領域とは？

拡張領域の違いはGTE CyberTrustルートとEntrustルートでは なくて、鍵長により微妙に拡張が違うようです。 これは鍵長2048bitのもの。

これは512bitのものです。

ニュースでは、通常TLSサーバー用とか TLSクライアント用とか書かれる 拡張鍵使用目的(Extended Key Usage)がないとか、他にも 拡張でおかしなところがあると言っています。 おかしなところをヤバい順にまとめてみましょう。

CRL配布点(CDP:CRL Distribution Points)が無い

これが無いため証明書を失効させることができません。 今回のように発行した証明書に問題があった時に失効できないことはホント致命的。

KeyUsageがないものがある

512bit RSA鍵の場合に拡張が無いようです。 RFC 3280的にはTLSでは署名検証に使うので必須(MUST)ですね。

拡張鍵使用目的(EKU:Extended Key Usage)がない

必須ではなかった気がしますが普通ついてます。

KeyUsageがあっても、不要なビットが立っている

Key Usage拡張は512bitより大きい鍵の証明書では有るようですが、 値としてDigital Signature、Non-Repudiation、Key Encipherment、 Data Enciphermentのビットが立っています。 SSLサーバー証明書ではNon-Repudiation、Data Enciphermentは余計ですよね。

RFC 5280 4.2.1.12 Extended Key Usageより
If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions.
中略
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement

RFC 5280ではExtended Key UsageとKey Usageが一貫している 事がMUSTになっています。

基本制約(Basic Constraints)が無い

なければ認証局証明書でないってことなんですが、一般にはつけることが多いですよね。 随分昔、あるメーラーで基本制約が無いことを無視して、ユーザ証明書から下位証明書発行しても検証成功だったことを発見してしまったり、、、

Authority/Subject Key Identifierで64bitは最近珍しい

ですよね？

結局、CRL配布点拡張がなく失効できないというのが一番の問題 だったんだと思います。失効できていれば、 単に問題のあった証明書を失効させ、鍵長や拡張領域に 問題があったとしても正しいものを再発行すれば よかっただけで、こんなに大きな問題にはならなかったはずです。 失効できないために認証局丸ごとブラックリスト化するしか 手が無かったわけです。 ニュースではEKUが無いのがおかしいとか わけのわからない事指摘してますよね。

CPS(認証実施規程)と照らしてどうなの？

認証局ではCPS(認証実施規程)で定めた運用に従い 証明書を発行するわけですが、これと照らしてどうだったのか Digicert SdnのCPSを ちょっと見てみました。

• 鍵長が512bit以下ではダメだという記述は見当たらなかったので CPS的に512bitの鍵に対して証明書発行することは問題が無かったようだ。
• 拡張領域については単に使用可能な拡張をまとめているだけで 発行する証明書の用途ごとに証明書プロファイルを定めて いなかったのでCDP拡張など拡張が不足していたり問題があったと してもCPS違反になることは無い。

とまぁ、このような感じでCPSに違反しているということは 無かったようです。

ただ、CPS中の証明書プロファイルについて、どのような拡張が 必ず含まれるのか、含まれないのか明確になっておらず、 CRL配布点拡張が無いという認証局設計上の重大な欠陥が 明らかになってこなかったという問題はありますけどね。

今回の問題に対する評価はこれでいいのか

今回の問題は、COMODOやDigiNotarのように攻撃されて サブCAやRAが乗っ取られ不正な証明書を出し放題になっていたわけでも なく、同列に問題を語られているのは違和感を覚えます。 高々、認証局ではなくSSLサーバ証明書の鍵が不正に使われるだけですよね。 512bit鍵の証明書を発行してしまったのは、利用者(お客さん)にも 問題があったわけですよね。 とても悔やまれるのはCRL Distribution Points拡張が 入っていなかったその一点です。 それさえ入っていれば、問題が発覚しても 単に証明書再発行すれば済んだのに、 中間CA証明書のブラックリスト入りという結果になってしまいました。 同じCAから発行されているSSLサーバー証明書でも 拡張のまともなものもあり

完全にとばっちりを食ったお客さんも多数いるわけですよね。 可哀想だなぁと思います。

GTE CyberTrust Global Rootを運用しているVerizonからは 何のコメントも無いのも変な感じですよね。

おわりに

以上、マレーシアのDigicert Sdnの認証局の問題について ちょっと調べたところを報告しまいた。 512 bit RSA鍵が問題だみたいなニュースの論調ですが、 あれはユーザの鍵なのでCA鍵と違って危殆化しても大した問題では なくて、それよりもCRL配布点拡張が無いことにより失効の手立てがなく、 中間CA自体を廃棄するしか手が無かったってことが問題だったわけです。

やべやべ、夜更かししちゃったよ。 ではでは、、、

関連リンク

• threat post 2011.11.03: Malaysian CA Digicert Revokes Certs With Weak Keys, Mozilla Moves to Revoke Trust
• SOPHOS Naked Security 2011.11.03: Another certificate authority issues dangerous certficates
• (マレーシアの)digicert Certification Authority
  • 本件のお知らせ
  • CRLリポジトリ
• 米ユタ州のDigiCert - DigiCert, Inc. Of No Relation to Recent "Digi" Insecure Certificates
• Entrust - Entrust Bulletin on Certificates Issued with Weak 512-bit RSA Keys by Digicert Malaysia
• ITmediaニュース 2011.11.04 SSL認証局問題が再び発覚、MicrosoftとMozillaが対応表明 今度はマレーシアのSSL認証局が発行した証明書に問題が発覚した
• InfoWorld SECURITY CENTRAL 2011.11.04 Mozilla, Microsoft withdraw trust in Digicert certificates

小ネタ：FireFoxとIEでのIPアドレスのSubjectAltName dNSNameの扱いの違い

今日は小ネタです。

今日、某IPアドレスで書かれたサイトにHTTPSでアクセスしてみると うむむ、FireFox 3.6.23だと 信頼できない接続のアラートが、、、

IE8だと問題ありません。

んなアホな。 うむむと思ってSSLサーバー証明書を見てみると

SubjectAltNameのGeneralName値が

dNSName: 192.168.1.5

みたいにDNS NameのところにIPアドレスが 書いてある証明書のせいみたいなんです。

RFC 3280 ではsubjectAltNameにドメイン名を入れる場合には dNSNameフィールドに入れなければならず(MUST)、 RFC 1034の"prefered name syntax"でなければ ならない(MUST)となっています。

RFC 3280 4.2.1.7 SubjectAltNameより
When the subjectAltName extension contains a domain name system label, the domain name MUST be stored in the dNSName (an IA5String). The name MUST be in the "preferred name syntax," as specified by RFC 1034 [RFC 1034].

で、RFC 1034のpreferred name syntaxを見てみると 普通のFQDNドメイン名でありラベルの先頭は英大小文字の A-Zにでなければならないので、 dNSNameには "192.168.1.5" のようなIPアドレスは 入れてはならないことになります。

IPアドレスを指定したい場合にはiPAddressフィールドが使えますよね。

GeneralName ::= CHOICE {
　　 otherName　　　　　　　　　　　 [0]　　 OtherName,
　　 rfc822Name　　　　　　　　　　　[1]　　 IA5String,
　　 dNSName　　　　　　　　　　　　 [2]　　 IA5String,
　　 x400Address　　　　　　　　　　 [3]　　 ORAddress,
　　 directoryName　　　　　　　　　 [4]　　 Name,
　　 ediPartyName　　　　　　　　　　[5]　　 EDIPartyName,
　　 uniformResourceIdentifier　　　 [6]　　 IA5String,
　　 iPAddress　　　　　　　　　　　 [7]　　 OCTET STRING,
　　 registeredID　　　　　　　　　　[8]　　 OBJECT IDENTIFIER }

FireFoxは厳密にsubjectAltName dNSNameをみて それがFQDNでないとリジェクトしちゃうけども、 IE8はIPアドレスが書いてあっても通してしまうと、、、 結局は発行した証明書のsubjectAltNameが 間違ってるってことなんですが誰に言えばいいんですかねぇ、、、

W3C XML暗号化の脆弱性に対するW3Cのコメントに「ちょっとなぁ」と思った件

2011年10月17日より米国シカゴで開催された国際会議 "18th ACM Conference on Computer and Communications Security" において、 Tibor Jager と Juraj Somorovsky により "How to Break XML Encryption" という発表がありました。 W3C勧告であるXML文書の暗号化の標準 "XML Encryption Syntax and Processing, 10 Dec 2002" においてAESでも3DESでもCBC(Cipher Block Chaining)モードを 使っている限り解読される可能性があるというものです。

これに対しW3Cは "Some notes on the recent XML Encryption attack" というコメントを発表しました。

これはぶっちゃけちゃうと「CBC使わずにGCM(Galois Counter Mode)なんかを使ってね。 標準にもなってるしね。」という内容なんですが、 標準になっているといってもOPTIONALですよね。

引用：W3C XMLEnc 5.2.4 AES-GCM
- http://www.w3.org/2009/xmlenc11#aes128-gcm (OPTIONAL)
- http://www.w3.org/2009/xmlenc11#aes256-gcm (OPTIONAL)

AES-GCMをサポートするXML暗号化ライブラリなんてあるのかと ちょっと調べてみました。

手軽に手に入りやすそうな比較的メジャーなJava XML暗号ライブラリというと こんなところかと思います。

• Apache Santuario/XML Security for Java - サポートするアルゴリズム情報
• IAIK XML Security Toolkit (XSECT) - サポートするアルゴリズム
• IBM SDK Java Technology Edition Verion 7

Sun/Oracle JavaのXMLはXML署名しか含まれていません。 サポートするアルゴリズム情報をApache, IAIKで見てみましたが AES-GCMはサポートされていないようです。 IBM Java SDKについても検索してみましたが、どうやらGCMはサポートしていないようです。 Javaでこれだけダメなんだから、他の言語用のライブラリはもっと ひどいはず。Microsoft .NETについてもGCM必須なSuite-B対応が進んでいるので もしやとおもいましたが、どうやらダメなようです。

結局、W3Cは「GCM使えばいいじゃん」というものの「使えそうな実装がない」 という、何ともとほほな状況であることがわかりました。 自前でAES-GCM対応するしかないですかね。

祝iOS5リリース記念(その2)：iOS5のS/MIME署名・暗号メールのフォーマット、アルゴリズムを見てみたぞ

前回はApple iOS 5のメーラーの新機能であるS/MIME署名暗号メールを 送受信してみるあたりを見てきましたが、今日はその中身を覗いてみましょう。 (結論からいうとフツーすぎてかなりがっかり)

まずメッセージヘッダの特徴的なところを

iOS5から送られたS/MIME署名メールについて メッセージ本体のヘッダで特徴的なところを抜き出すとこんな感じ。

Content-Type: multipart/signed;
　　　　micalg=sha1;
　　　　boundary=Apple-Mail-XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX;
　　　　protocol="application/pkcs7-signature"
X-Mailer: iPhone Mail (XXXXX)
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)

S/MIME署名メールはクリアテキスト形式になっており 署名データのMIMEヘッダはこんな感じ。

Content-Disposition: attachment;
　　　　filename=smime.p7s
Content-Type: application/pkcs7-signature;
　　　　name=smime.p7s
Content-Transfer-Encoding: base64

まぁ、至って普通です。

署名データの中身は

PKCS#7 SignedData形式である署名データを覗いてみて 特徴をまとめてみました。

フィールド	値
version(SignedData)	1
digestAlgorithms	SHA1
certificates	EE証明書のみ

SignedDataの中のSignerInfoの特徴はこんな感じ。

フィールド	値
version(SignerInfo)	1(=IssuerSerial)
digestAlgorithm	SHA1

SignerInfoの中の署名属性(signedAttributes)の一覧は以下の通り。

フィールド	値
contentType	data
signingTime	UTCTime
messageDigest	署名対象のSHA1ハッシュ値
microsoftRecipientInfo(1.3.6.1.4.1.311.16.4)	受信者のIssuerSeiralセット
encrypKeyPref(1.2.840.113549.1.9.16.2.11)	送信者の暗号用証明書のIssuerSerial
signatureAlgorithm	rsaEncryption(1.2.840.113549.1.1.1)

暗号データの中身

次にPKCS#7 EnvelopedData形式である暗号データを覗いてみました。 特に特徴的なところはなくてTriple DES EDEモード(des-EDE3-CBC 1.2.840.113549.3.7) が使われているというだけでしょうか。

まとめ

というわけで、iOS5のメールのS/MIME機能は使われている フォーマットや暗号アルゴリズムは至って普通で とても相互運用性が高いものになっていると言っていいんでしょうかね。 うーん、つまらん。