2009年01月27日

RFC 5280 の 4.2.1.3. Key Usage

Key Usage は「キー使用法」
証明書に署名した認証局が
その証明書の公開鍵の使用方法として認めてる用途のリストになります
用途を制限したいときにはこの拡張を使います (無制限なら書かない?)
ASN.1 モジュールはこんなかんじ
id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }

KeyUsage ::= BIT STRING {
     digitalSignature        (0),
     nonRepudiation          (1), -- recent editions of X.509 have
                          -- renamed this bit to contentCommitment
     keyEncipherment         (2),
     dataEncipherment        (3),
     keyAgreement            (4),
     keyCertSign             (5),
     cRLSign                 (6),
     encipherOnly            (7),
     decipherOnly            (8) }
で、想定されてる用途がリストされています
例えば ssl.seesaa.jp の証明書だと keyUsage 部分の dump は
30 0e
   06 03
      55 1d 0f
   01 01
      ff
   04 04
      03 02
         05 a0
これを読み下すと
SEQUENCE で長さは 13 bytes
   OID で長さは 3 bytes
      2.5.29.15 = Key Usage
   BOOLEAN で長さ 1
      True (Critical)
   OCTET STRING で長さは 4 bytes
      BIT STRING で長さは 2 bytes
         未使用 bit 数は 5 bit の 10100000 = 101 (0 と 2)
なので Key Usage はクリティカルで用途は digitalSignature と keyEncipherment
ってことが分かります

RFC 5280 に従うならば
「他の証明書や CRL の署名を検証する為に使う公開鍵を含む証明書」
(ってことは認証局の証明書?)
にはこの拡張を含めなくてはいけません (MUST)
で、含めるんだったらクリティカルにすべきです (SHOULD)

では、上に挙げた用途の詳細を簡単に列記
  • digitalSignature は証明書と CRL 以外の署名を確認する為、認証・整合性用
  • nonRepudiation は証明書と CRL 以外の署名を確認する為、否認防止用
  • keyEncipherment は秘密にしたい鍵の暗号化用
  • dataEncipherment は共通鍵無しに (ハイブリッドでなしに?) 直接暗号化する用
  • keyAgreement は、Diffie-Hellman 鍵交換とか鍵を共有する用
  • keyCertSign は証明書の署名検証用、これは basic constraints の cA がセット (MUST)
  • cRLSign は CRL の署名検証用
  • encipherOnly は keyAgreement を更に暗号するだけに制限する
  • decipherOnly は keyAgreement を更に複号するだけに制限する

注をいくつか

keyUsage が設定されてるのに keyCertSign や cRLSign のビットは立ってないときは
その証明書に入ってる公開鍵を使って証明書や CRL の署名を検証してはいけません
(MUST NOT)

証明書の公開鍵を証明書や CRL の署名の検証だけに使わせたいなら
digitalSignature と nonRepudiation は立てるべきではありません (SHOULD NOT)
もちろん、他の署名の検証に使っても良いなら色々立ってても OK (MAY)

RFC 5280 は用途の組合せを特に制限しませんが
公開鍵によって適切な値ってのはあるので守りましょう
例えば DSA は署名アルゴリズムだから暗号化できませんし
詳しくは RFC の 3279, 4055, 4491 を見ましょう

keyUsage を設定しといて用途の bit を全て 0 にすると無駄なので
最低 1 つは 1 でなくちゃいけません (MUST)

で、
nonRepudiation と他の用途との組合せに関して何か書いてあるんだけど
Combining the nonRepudiation bit in the keyUsage certificate
extension with other keyUsage bits may have security implications
depending on the context in which the certificate is to be used.
Further distinctions between the digitalSignature and nonRepudiation
bits may be provided in specific certificate policies.
意味が分かりません
そもそも nonRepudiation と digitalSignature を分ける理由が分からない
でも分けてるからには何か意味があるんでしょう、policy の話なの?
読み進めていったら分かるかなぁ
ラベル:拡張 公開鍵 RFC5280
posted by OJH at 02:49| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年01月22日

RFC 5280 の 4.2.1.2. Subject Key Identifier

「サブジェクト鍵識別子」ですね、直訳
証明書に含まれる公開鍵の持ち主を一意に指し示す為の項目です

id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }

SubjectKeyIdentifier ::= KeyIdentifier

これも証明書の信頼の階層構築の為に使います
階層の確認のときに誰が署名したか直ぐ分かると楽ですから
認証局は発行した証明書に Authority Key Identifier を書いて
認証局の証明書には Subject Key Identifier を書いとかないといけません (MUST)

じゃぁ認証局の証明書て何だよ、ということになるわけですが
basic constraists っていう拡張で cA が True になってる証明書が
認証局の証明書だということになるそうです、がまぁそれは後ほど

で、この認証局の証明書の Subject Key Identifier と
その認証局が発行した証明書の Authority Key Identifier が
一致しなくてはいけません (MUST)
一致してたら誰の署名した証明書かとか探すのも簡単ですね

でも、基本は Distinguished Name に書かれてる情報ですし
証明書のパスを検証するソフトはここを見なくてもかまいません

エンドエンティティーの証明書の場合でも
例えば複数の証明書を複数の認証局から取得してる場合に
アプリケーションでどの証明書を用いるか直ぐ分かるように、など
証明書がどの公開鍵を含んでるかってことを指し示すのに使います

認証局の証明書の場合は Subject Key Identifier は書かないといけませんでしたが
エンドエンティティーの場合は「すべき」に抑えられています (SHOULD)

Subject Key Identifier は、公開鍵からかもしくは他の方法を用いて作った
一意に定まるような値を入れとくべきです (SHOULD)
で、一般的なのは
  1. subjectPublicKey を SHA-1 にかける (ただしタグとか長さの部分を除いたものを)
  2. 4 bit 0010 の後に、上の値の下位 60 bits を続けたもの
まぁ、これらは飽くまで一例で、他の方法でも OK です

あらかじめ identifier が作ってなければ、上の方法がお薦めですし (RECOMMENDS)
あらかじめ identifier が作ってあればそれを使うべきです (SHOULD)

ノンクリティカルでなくてはいけません
posted by OJH at 00:58| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年01月20日

研究者がMD5の衝突によりAuthenticodeで署名された実行ファイルを生成

コードサイニング、お前もか
研究者がMD5の衝突によりAuthenticodeで署名された実行ファイルを生成
って思ったんですが何となく
「あ、この方法だったらコードサイニングでもできるじゃん」
つってイージーに論文書いたんじゃないの? と邪推したくなったりもします。

ハッシュ値の間に距離のようなものが定義されていて
MD5 の計算の途中から 2 つの値の距離を徐々に短かくしていって
結果二つのハッシュ値を等しくしようとするならば
元のデータは多分大きい方が有利なんではないかと思って
特に実行ファイルは無意味なデータも格納し易い気がするし
証明書は 2kb で実行ファイルは 6kb ですか

ってまぁ、詳しい解説読んでないので完全な邪推なのですが
コードサイニング? って感じなのと合わせて
先に MD5 な SSL サーバー証明書への攻撃の方を
より深く理解したいという希望があるので
もうすこし後から勉強したらということでとりあえずご報告
posted by OJH at 04:07| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする

2009年01月17日

IPA、暗号アルゴリズム確認制度を追加

IPA、暗号アルゴリズム確認制度を追加、だそうです
JCMVP っていうと前にサイドチャネル攻撃の評価ボードの
SASEBO のこと聞いたとき始めて聞いたんですが
"Japan Cryptographic Module Validation Program" の略で
暗号の実装がちゃんとされてるかとかの認証しようって制度でした
フツーはソフトが取るみたいですが SASEBO はハード実装で始めてだった、と

JCMVP が今までしてた色々な審査のうちの 1 つである
暗号アルゴリズムの実装部分の審査だけ取り出して
独立して認証するようになったのだそうです

暗号アルゴリズムの実装部分ってのは自動で確認できるようで
1 週間で済むとか書いてありました
他の部分は鍵の管理方法とか人が入るから時間も費用もかかるけど
実装は自動で短期間でできちゃうし大切な部分だから独立させた
ってことかな?

とあるシステムの暗号部分って感じではなくて
単純な暗号用ソフトウェアでも取れるということなのかなぁ
例えば OpenSSL とか?
Java とか GnuTLS とかも??
posted by OJH at 04:48| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする

2009年01月16日

RFC 5280 の 4.2.1.1. Authority Key Identifier

Authority Key Identifier はマイクロソフト社では「機関キー識別子」となってます
発行者が署名に使っている公開鍵を識別する為の識別子です
1 つの発行者が同時に複数の鍵を利用していたり鍵を変更した場合があるので
機関キー識別子によって証明書の階層の確認を簡単にすることができます
具体的に何が入っているかというと
  • 発行者の証明書の subject key identifier と同じもの
  • 発行者の名前とその証明書のシリアル番号
のどちらかが基本となる情報です

ASN.1 モジュールはこちら
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }

AuthorityKeyIdentifier ::= SEQUENCE {
   keyIdentifier             [0] KeyIdentifier           OPTIONAL,
   authorityCertIssuer       [1] GeneralNames            OPTIONAL,
   authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }
RFC 5280 に従う場合
認証局は発行する証明書には必ず keyIdentifier を指定しなくてはいけません (MUST)
但し証明書の階層の確認を簡単にする為なので
自己署名証明書の場合には指定しなくても構いません (MAY)
その変わり次節の Subject Key Identifier は記載する必要があります

keyIdentifier はその公開鍵から作られるか
または何かしらの方法で一意に定まった値であるべきです
具体的な作成方法に関しては次節で述べられます
事前の keyIdentifier がある場合にはそれを使うべきだし (SHOULD)
事前には無かった場合には RFC 5280 で書かれている方法か
若しくはそこからハッシュ関数を変更などを使うのがお薦めです (RECOMMENDS)

最後に 2 つ RFC 5280 に従う場合
  • 証明書を解釈するアプリなどは機関キー識別子をサポートすべきです (SHOULD)
  • 認証局はこの拡張をクリティカルにしてはいけません
posted by OJH at 04:21| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年01月13日

RFC 5280 の 4.2.1. Standard Extensions

この節以下で
X.509 バージョン 3 で定義されている標準的な拡張に関して
その OID も含めてその詳細が説明されていきます
具体的に目次を見てみると
  • 4.2.1.1. Authority Key Identifier (OID = 2.5.29.35)
  • 4.2.1.2. Subject Key Identifier (OID = 2.5.29.14)
  • 4.2.1.3. Key Usage (OID = 2.5.29.15)
  • 4.2.1.4. Certificate Policies (OID = 2.5.29.32)
  • 4.2.1.5. Policy Mappings (OID = 2.5.29.33)
  • 4.2.1.6. Subject Alternative Name (OID = 2.5.29.17)
  • 4.2.1.7. Issuer Alternative Name (OID = 2.5.29.18)
  • 4.2.1.8. Subject Directory Attributes (OID = 2.5.29.9)
  • 4.2.1.9. Basic Constraints (OID = 2.5.29.19)
  • 4.2.1.10. Name Constraints (OID = 2.5.29.30)
  • 4.2.1.11. Policy Constraints (OID = 2.5.29.36)
  • 4.2.1.12. Extended Key Usage (OID = 2.5.29.37)
  • 4.2.1.13. CRL Distribution Points (OID = 2.5.29.31)
  • 4.2.1.14. Inhibit anyPolicy (OID = 2.5.29.54)
  • 4.2.1.15. Freshest CRL (a.k.a. Delta CRL Distribution Point) (OID = 2.5.29.46)
になります

ASN.1 モジュールで見るとこんな感じ
id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }
id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
id-ce-certificatePolicies OBJECT IDENTIFIER ::=  { id-ce 32 }
id-ce-policyMappings OBJECT IDENTIFIER ::=  { id-ce 33 }
id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }
id-ce-issuerAltName OBJECT IDENTIFIER ::=  { id-ce 18 }
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::=  { id-ce 9 }
id-ce-basicConstraints OBJECT IDENTIFIER ::=  { id-ce 19 }
id-ce-nameConstraints OBJECT IDENTIFIER ::=  { id-ce 30 }
id-ce-policyConstraints OBJECT IDENTIFIER ::=  { id-ce 36 }
id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::=  { id-ce 31 }
id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::=  { id-ce 54 }
id-ce-freshestCRL OBJECT IDENTIFIER ::=  { id-ce 46 }
ce は certificates の ce?
ラベル:RFC5280 拡張 OID
posted by OJH at 02:33| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年01月12日

RFC 5280 の 4.2. Certificate Extensions

RFC 5280 の 4.2. Certificate Extensions

X.509 バージョン 3 で定義された拡張部分は
  • 利用者の詳しい情報
  • 公開鍵の詳しい情報
  • 認証局の間の関係
を記載する為に用意されました
「署名前証明書」の最後の部分に羅列されます
X.509 バージョン 3 では独自の拡張を追加することも想定しています

拡張部分の ASN.1 モジュールは以下の通りです:
   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING
                    -- contains the DER encoding of an ASN.1 value
                    -- corresponding to the extension type identified
                    -- by extnID
        }
具体的にはこんな感じ
拡張

拡張には「OID・クリティカル・ASN.1 なビット列」の 3 つが記載されます
特定の拡張を 1 つの証明書に複数記載してはいけません (MUST NOT)
OID で拡張の種類が記載され、その内容がビット列で表現されます

クリティカルにはその拡張の重要度が True/False の BOOLEAN で記載されています
デフォルトは False です
  • 知らない・処理できないクリティカルな拡張があったらその証明書を拒否しないといけない (MUST)
  • 知らないクリティカルではない拡張があったら無視して良い (MAY)
  • 知っている拡張はクリティカルでなくても処理しなくてはいけない (MUST)

拡張を追加するのは構わないのですが、
クリティカルな拡張の扱いは気をつけて一般的な利用の妨げとならないようにしましょう。

以下の節では
インターネット PKI で使われる証明書に載せるお薦めの拡張と
どんな情報をどの拡張に載せるべきかということが述べられます。
クリティカルをどうすべきかも記載されます。

RFC 5280 で認証局がサポートすることが必須 (MUST) となっている拡張は
(認証局の証明書に記載されているべき拡張は?)
  • authority key identifiers (Sections 4.2.1.1)
  • subject key identifiers (Sections 4.2.1.2)
  • basic constraints (Section 4.2.1.9)
  • key usage (Section 4.2.1.3)
  • certificate policies (Section 4.2.1.4)
です
更に、サブジェクトが空の証明書には
  • subject alternative name extension (Section 4.2.1.6)
が記載されていなくてはいけません (MUST)

その他の拡張は OPTIONAL となります
RFC 5280 に従う認証局は RFC 5280 に載ってない拡張も処理できた方が良いです
証明書を発行者するとき RFC 5280 に載ってない拡張を載せることもできますが
クリティカルにしてしまうと相互運用を妨げてしまうので注意しましょう

証明書を利用するアプリケーション側で最低限知らないといけない拡張は (MUST)
key usage (Section 4.2.1.3)
  • certificate policies (Section 4.2.1.4)
  • subject alternative name (Section 4.2.1.6)
  • basic constraints (Section 4.2.1.9)
  • name constraints (Section 4.2.1.10)
  • policy constraints (Section 4.2.1.11)
  • extended key usage (Section 4.2.1.12)
  • inhibit anyPolicy (Section 4.2.1.14)
更に、以下の拡張を知っているべきです (SHOULD)
  • authority key identifiers (Sections 4.2.1.1)
  • subject key identifiers (Sections 4.2.1.2)
  • policy mappings (Section 4.2.1.5)
posted by OJH at 20:47| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年01月08日

ユークリッドの互除法

ユークリッドの互除法が頭から抜けていたので復習しました

a > b > 0 を正の整数とする
a を b で割った商を q 余りを r とする
a = b × q + r
このとき 0 ≦ r < b の条件の下 q と r は一意

a = r0、b = r1 と思いこれを繰り返す
r0 = r1 × q2 + r2 (0 ≦ r2 < r1)
r1 = r2 × q3 + r3 (0 ≦ r3 < r2)
r2 = r3 × q4 + r4 (0 ≦ r4 < r3)
・・・
rn-2 = rn-1 × qn + rn (0 ≦ rn <rn-1)
rn-1 = rn × qn+1 + 0
ri は 0 以上でどんどん小さくなるのでいつかは 0 となる
上は n+1 番目で 0 となるとした場合の表示

このとき、a = r0 と b = r1 の公約数 d は全ての ri を割る
d は各左辺を割り切るので右辺も割り切らないといけないから
特に d は a と b の最大公約数であったとしても rn を割り切る
逆に一番下から見ていくと rn は rn-1 を割り切るので
1 つ前に戻って rn-2 も割り切り、繰り返すと a = r0 と b = r1 も割り切る
つまり rn は a と b の公約数
  • a と b の最大公約数は rn を割り切る
  • rn は a と b の公約数
rn は a と b の最大公約数ということ

上の式達を下から解いていくと rn を a と b を用いて表わすことができる
r0 = 1・a + 0・b
r1 = 0・a + 1・b
ri = xi a + yi b
と表現できたとする
ri = ri-2 - ri-1 qi
= (xi-2 a + yi-2 b) - (xi-1 a + yi-1 b) qi
= (xi-2 - xi-1 qi) x - (yi-2 - yi-1 qi) b
つまり
xi = xi-2 - xi-1 qi
yi = yi-2 - yi-1 qi
という漸化式が成立する

r0 = a, r1 = b だったので
x0 = 1, y0 = 0, x1 = 0, y1 = 1
という初期値から漸化式を解いていけば良い
例えば Python を使って例外処理を考えないと
def euclid(a, b):
if b == 0: return None

x0, y0, z0 = 1, 0, a
x1, y1, z1 = 0, 1, b

while z1 != 0:
r = z0 % z1
q = z0 / z1
x0, y0, z0, x1, y1, z1 = x1, y1, z1, x0 - x1 * q, y0 - y1 * q, r

return x0, y0, z0
とすると
(x, y, z) = euclid(a, b)
if x * a + y * b == z:
print "z is GCD"
というわけで最大公約数 z = x a + y b という x, y, z が求まる
posted by OJH at 02:16| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

RFC 5280 の 4.1.2.9. Extensions

tbsCertificate の最後が拡張部分です
最後といっても実際にインターネットに転がってる証明書を見ると
この拡張部分がずっと続いて今までの部分より長かったりしますが
Extensions は「拡張」と訳されていることが多いのかな?

拡張は X.509 のバージョン 2 までの問題点を解決する為に設定されたので
記載するには証明書のバージョンを 3 に設定しなくてはいけません (MUST)

ASN.1 モージュールを確認すると、
   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING
                    -- contains the DER encoding of an ASN.1 value
                    -- corresponding to the extension type identified
                    -- by extnID
        }
とあるように Extension の列であり
中身は
  • OID
  • クリティカルかどうか
  • 内容を表わすビット列

で、具体的にどんな Extension があるか?
というのが次節 4.2 以降で説明されます
ラベル:RFC5280 拡張
posted by OJH at 00:05| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年01月05日

RFC 5280 の 4.1.2.8. Unique Identifiers

サブジェクトと発行者を一意的に指し示す情報を記載する部分です
サブジェクトや発行者の名前を再利用する為のものだそうです
ただ、RFC 5280 では利用は推奨されてません (not RECOMMENDS)
また、インターネットで利用される証明書では使わないそうです
他の利用方法ではサブジェクトや発行者を省略してここを使うのかな?

RFC 5280 に従う認証局は Unique Identifiers を記述してはいけません (MUST NOT)
インターネットでは使わないというのだから当然ですね
RFC 5280 に従うソフトはこの項目の含まれた証明書を読み込んでも
エラーで止まったりせずに他の項目を正しく処理し切れるべきです
どんな証明書が来ても対応できる柔軟さは求められます
しかし、その中身まで理解したりできなくてもかまいません
無視しましょう、華麗にスルーです

若しインターネットでない用途などで記載するなら、
X.509 的には証明書の Version が 2 か 3 でなくてはいけません (MUST)
posted by OJH at 23:00| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年01月04日

Digital Signature Algorithm (DSA)

電子署名の方法は RSA + ハッシュしか良く知らなかったので
他のもということで DSA について調べてみました

電子署名アルゴリズムの 1 つ DSA は Digital Signature Algorithm の略
例えば NIST の FIPS 186 で文章化されています

FIPS 186-2 では鍵長は 1024bit で使うハッシュ関数は SHA-1 としていますが
暗号の 2010 年問題というやつで SHA-1 や鍵長に限界が感ぜられているので
FIPS 186-3 がまだ草案ですが鍵長は 3072bit までで SHA-2 が使えるようになる予定です

DSA のパラメータ

DSA ではアルゴリズムにパラメータが指定されます
鍵長を L bit、ハッシュ値の長さを N bit とします
ハッシュ関数はハッシュ値として N bit なものを出力するとします

  • 大きな素数 p を 2L-1 < p < 2L となるように選びます

  • p-1 の素因数 q を 2N-1 < q < 2N の範囲で選びます
p は奇数なので p-1 は偶数となり自明でない素因数分解ができます
(実際には q を選んで n もランダムで選んで p = q n + 1 が素数かチェックする?)

  • mod p の世界で q 乗して初めて 1 になる数 g を探します (1 < g < p)
(mod p = p で割った余りを考えろ、と読みましょう)
p は素数なので mod p の世界は有限体となり乗法群の位数は p-1
p-1 の素因数である q を位数とする元 g が存在するはずなので選びます

以上の (p, q, g) の triple が DSA のパラメータとなります

DSA の秘密鍵・公開鍵

次に秘密鍵・公開鍵を作ります、といっても簡単で
  • x を 0 < x < q で選んで秘密鍵とする
  • y = gx mod p を公開鍵とする
送信者は受信者に {(p, q, g), y} というデータを渡すことになります

DSA の署名と検証

署名しましょう
平文 M のハッシュ値を z とします

  • 整数 k を 0 < k < q となるように選びます (x 同様内緒にします)
  • r = (gk mod p) mod q とします
  • s = k-1 (z + x r) mod q とします
この (r, s) が署名となります
k は M 毎に選びます、同じものを再び使うことのないようにします
r と s のどちらかが 0 になってしまった場合、k を選ぶところからやり直します

というわけで、メーッセージの受信者は
  • (p, q, g) と y と z = Hash(M) と (r, s) を知っていて
  • x と k は知らない
という状況になります
x と k を使わずに r を表現する方法を作れれば検証方法確立です

(gz yr)(s-1) mod p
を考えます. y=gx を使えばこれは
g(z + x r) (s-1) mod p
です
gq = 1 mod p だったので g の肩は mod q の世界でした
s の定義を見てみればこの値は
gk mod p
なので更に mod q とってやれば
((gz yr)(s-1) mod p) mod q = r
となります
左辺は x も k も使わない表現で r を表わすことができました

なので、受信者は
  • アルゴリズムパラメータ (p, q, g)
  • 公開鍵 y
  • 平文 M
  • ハッシュ関数
  • 署名 (r, s)
が与えられたとき、(r, s) の検証がしたければ
((gz yr)(s-1) mod p) mod q = r
が成立するかどうか確認すれば良いことになります

DSA の雑感

署名を偽造する一番素直な方法は
  • y = gx となる x を求める
  • ((gz yr)(s-1) mod p) mod q = r となる s を求める
のどちらかでしょうか
ここで後者の場合 k は攻撃者が選んで良いので r は知ってます
どっちも計算大変だよね? というのが署名を信頼する元になっています
なので p, q が大きいことが大切になってきます

q を使う理由は、単純に mod p の世界で考えてしまうと
平方剰余の乗法性を用いて既知のデータから未知のデータが類推し易くなるから
k をランダムで選ぶと既存の平文と署名から検証可能な平文と署名が作れちゃうとか
色々と知るべきことが残っていそうなんですがとりあえず DSA の流れということで

ちなみに、未だに s の形があの形なことが納得し切れていません
積だけだと攻撃に弱そうなことは分かるんですが.....
ラベル:DSA 署名
posted by OJH at 15:58| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2009年01月03日

RFC 5280 の 4.1.2.7. Subject Public Key Info

証明書は公開鍵証明書なわけで、遂に公開鍵がやってきました
subjectPublicKeyInfo には
   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

   AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }
が入っています

証明書の三大要素の 2 つ目が signatureAlgorithm でしたが
ここで AlgorithmIdentifier を見ました
アルゴリズムやエンコードの仕方を指す OID は
RFC 3279, RFC 4055, RFC 4491 なんかを見れば良いのでした

例えばアルゴリズムと OID は
rsaEncryption -> 1.2.840.113549.1.1.1
dsa -> 1.2.840.10040.4.1
dhpublicnumber -> 1.2.840.10046.2.1
なんてのがあります
posted by OJH at 03:50| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年01月02日

RFC 5280 の 4.1.2.6. Subject

Subject はこの証明書の「主題」っつうことで証明書を発行した対象です
subjectPublicKeyInfo に載っている公開鍵の持ち主の情報が載ってます
「サブジェクト」って訳されていることが多いです
サブジェクトの名前はこの Subject か
拡張部分の subjectAltName に載せることになります

後で見ることになりますが、4.2.1.9. Basic Constraints は
公開鍵ペアの利用方法の許可範囲を記述する拡張部分で?
例えばその公開鍵ペアで証明書を発行して良いかどうかが書けます
で、その証明書が認証局の証明書として使う場合には
証明書の Subject に空ではない DN を設定して (MUST)
認証局の証明書のサブジェクトと発行した証明書の発行者を一致させます (MUST)

やっぱり後で見ますが 4.2.1.3 Key Usage で発行者は
公開鍵ペアの利用方法の範囲を指定します
例えばここで CRL に署名できるかどうかが指定できるのですが
Subject で示されるエンティティが CRL に署名する場合には
証明書の Subject に空ではない DN を設定して (MUST)
サブジェクトの DN と同じものを CRL の発行者部分に記載します (MUST)

メールアドレスや URI にのみ証明書の有効範囲を制限したい場合など
拡張部分の subjectAltName にのみ名前情報を載せることになります
その場合は Subject は空でなくてはいけません (MUST)
また、subjectAltName には critical というマークが付いてないといけません

クリティカル (critical) というのはフィールドに持たせる属性の 1 つで
クリティカルという印が付いているかいないかのどちらかになります
「○○であるためには××はクリティカルでなくてはいけない」
「○○であるためには××はクリティカルであってはいけない」
といった感じで証明書のコントロールに使われます

サブジェクトが空でないならば
発行者のときと同じように X.500 の名前のルールに従わなくてはいけません (MUST)
サブジェクトと発行者の DN のペアは
発行対象のエンティティーに対してユニークにしなくてはいけません (MUST)
ここで、ユニークの意味ですが、多分、1 つの発行者の DN に対して
異なるサブジェクトエンティティーには異なる DN を振れということだと思います
多分、多分ですが同じ会社が同じ FQDN で OU など変えても証明書は取得できるかと
また、同じ DN で同じエンティティーに証明書を発行するのは OK です (MAY)

名前に関するルールが書いてあるんですが
4.1.2.4 の発行者の部分と基本的には同じです
・名前の記述方法は X.501 に書いてある
・国名や組織など発行者の部分で理解できた属性は理解できないと (MUST)
・市区町村など発行者の部分で理解できるべきだった属性も同様 (SHOULD)
・書き方とか OID は Appendix A に書いてある
・Section 7.1 にある比較方法を使った方が良い (MAY)

使うべきエンコーディングは PrintableString か UTF8String ですが
発行者のときと同様に互換性などを保つ為の例外は許されています
認証局はよっぽどな理由がない限り PrintableString か UTF8String を使い
利用者側はどんなエンコーディングが来ても大丈夫なようにすべきです

例えば
昔はメールアドレスはサブジェクトの DN に記述されていました
RFC 2985 にも色々な属性が定義されていてメールアドレスも記述されていました
メールアドレスは @ を含みますがこれは PrintableString には含まれず
IA5String が使われています
また、メールアドレスは大文字・小文字を区別しません

RFC 5280 に従って新たに証明書を発行する場合には
メールアドレスは SubjectAltName (Section 4.2.1.6) 拡張に
rfc822Name として記述しなくてはいけません (MUST)
古い環境との互換性と保つ為に、SubjectAltName と同時に
Subject にもメールアドレスを記載することは
避けるべきですが一応許されています
posted by OJH at 16:11| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年01月01日

COMODO のリセラーの Certstar が無審査で証明書を出しちゃった

ちょっと古い話になりますが MD5 の衝突の話と合わせて
COMODO のリセラーの Certstar が審査無しで証明書出しちゃったそうです

経緯はというと、Certstar は期限切れ間近のサイトの管理者宛に
「そろそろ更新時期ですよ、更新はこちらから」
みたいな DM をばんばん出しまくっていたらしく StartCom のお客さんにも来てて
StartCom の Eddy Nigg さんは ? と思って試しに買ってみたら審査が無い
あれれ?? と思って www.mozilla.com の証明書を申請してみたら取れちゃったそうです

商品は COMODO の PositiveSSL ってやつで
これはドメイン認証、VeriSign でいうところの Class 1 なやつなので
認証局は、例えば WHOIS から管理者メールアドレスを取得して
そのアドレスに申請の確認のメールを出して何かしらの方法で確認を取るんですが
今回の場合は何の確認も無いし発行しちゃったということみたいです

COMODO は信頼回復の為に何かしらしないとダメなのかなぁ
posted by OJH at 04:02| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする

MD5 considered harmful today: Creating a rogue CA certificate

MD5 の「衝突の脆弱性」を利用した具体的な攻撃方法が公表されてるそうです
MD5 で署名してる認証局に署名された中間認証局を偽造できるということのようです
こ、これは、やばい認証局のパスのルート証明書を全部捨てろということなのでしょうか
がレポートのページで、MD5 で署名している認証局のリストも出ています
偽造された証明書も載ってます (悪用できないよう有効期間は 2004 年で)

既に衝突を起こす良い方法はあるみたいで
正規に入手した証明書の署名部分をコピーすることに偽造証明書が作れるようです

正規な証明書はシリアルと有効期間の情報以外はそれなりにコントロールできますし
発行が自動化されている場合、シリアルと有効期限もそれなりに予測できて
申請のタイミングによってコントロールできると

偽造する方は正規なものに似せつつも
basic constraints に CA = TRUE と Path Length = None を入れておいて
無駄な拡張部分を作っておいてそこに発行されるであろう署名前証明書の公開鍵入れたりして
あとはブルートフォースなのかな? 署名前証明書のハッシュを衝突させることができて
対応する正規な証明書の署名をコピーすると偽造中間証明書の完成!!

MD5 への攻撃にとって署名前証明書の前半部分のコントロールが大切みたいで
シリアルや有効期限がそれなりにコントロールできないとダメみたいなので
その辺りで防御策が無いこともないけど、MD5 使わないでよ、ってことだそうです

これだけでフィッシングとしては効果的ですし
DNS キャッシュが汚染されてしまった日には証明書のパスをじっくり見ないと
防ぎようが無くって結構大変なことになってる気がします続きを読む
ラベル:MD5 CA 証明書 衝突
posted by OJH at 02:47| Comment(0) | TrackBack(1) | ニュース | このブログの読者になる | 更新情報をチェックする
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。