2008年11月29日

RFC 5280 の 2.4. Administrator Expectation

管理者への要求か語られています。

2.3 では利用者への要求が述べられていましたが
それに加えて証明書の認証局を運営する人向けに
RFC 5280 の要求することが述べられています

認証局を運営する為には決めるべき証明書のポリシーが沢山あります
よっぽどの専門家でない限り何をどうするかを逐一決めるのは難しく
無駄なポリシーがあったり抜けがあったりするとその影響は
とても広い範囲にまで拡がってしまいます

また、下手なポリシーが指定されてしまうと
認証局によって証明書の信頼性の確認などの基準が変わってしまって
認証局毎にソフトウェアやライブラリを作成しなくてはいけなくなるかも

そのようなことが無いように新米認証局運営者でも
必要十分なポリシーでもって認証局を運営できるように
どのような設定をすべきか、守って欲しいことが書かれていますよ
ということだそうです

恐らくこれが真に RFC 3280 や RFC 5280 がしていることで、
証明書の信頼の階層の確認方法などが認証局毎に変わってしまうと
とあるブラウザで信頼できるとされる証明書が別のブラウザではダメとなり
じゃぁ一体どのブラウザで信頼されれば良いのか? なんて悩みが発生します
それは折角開かれているインターネットを閉じてしまうことになります
標準化による恩恵に与る為にも RFC 5280 に従って認証局を運営しましょう(!?)
posted by OJH at 23:40| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

Internet Week 2008 で暗号の話がありました

Internet Week 2008 が今週、秋葉原で行われていました
参加することはできなかったのですが
で暗号の話のレポートがあがっていました

インターネット上で決済することが日常になっていますが
安心してできているのは暗号化されているからだと思っているからです
でもその暗号化にも品質があるということまで考えていますか?
という問いかけになっています

暗号というのはいつかは破られるものであって
その時点の技術では当分は破られないだろうというものを使わないと
全く意味のないことをしていることになります
っていうことを理解してもらうのってとっても大変な気がします

エンドユーザーに「その時点での最良の暗号を選択してください」と言う
ってのは酷な話だと思うので気にせずとも暗号化が最良となっているような
環境を提供できるようになっていればいいのですがそれも中々難しく
あぁ、でも、OS が自然とバックアップを取るようになってきているなど
セキュリティーが気にせずとも保たれるようになってきているのかなぁ

「蛇口を開けば水が出る」ってのが理想なのでしょうか??
それとも皆がきちんとした知識を身につけるべきなのでしょうか???
posted by OJH at 03:16| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする

2008年11月28日

RFC 5280 の 2.3. User Expectations

RFC 5280 がインターネット PKI の「利用者」に「望む」ことが書かれています
望まれてることを一言で言うと「書いてあることに従ってね」ってことかもしれません

インターネット PKI の「利用者」とは、人やプロセスのうち
  • クライアントソフトウェアを利用する
  • 証明書のに証明される対象として記載されている
の 2 つの条件を満たすものです

利用者の具体例としては
  • 電子メールを読む/書く人 (S/MIME でメール暗号化・署名・否認拒否)
  • WWW クライアント (クライアント認証と SSL 通信の暗号化)
  • WWW サーバー (サーバ認証と SSL 通信の暗号化)
  • IPSec で鍵を管理する人・プロセス (接続相手の認証)
等が挙げられています
通常、前半 2 つはメールアドレス、後半 2 つは FQDN が証明書に記載されます

ここ以降、英語がかなり怪しくなるのですが、まんま載せてしまうと:

This profile recognizes the limitations of the platforms these users
employ and the limitations in sophistication and attentiveness of the
users themselves.  This manifests itself in minimal user
configuration responsibility (e.g., trusted CA keys, rules), explicit
platform usage constraints within the certificate, certification path
constraints that shield the user from many malicious actions, and
applications that sensibly automate validation functions.

RFC 5280 は利用者の用いる環境や利用者自身の知識や注意力に限界があることを考慮しています。
このことは RFC 5280 に記載される
  • 「必要最低限の設定をする義務 」(例: 信頼する認証局の公開鍵の扱い)
  • 証明書に記載される「具体的な環境の用途の制限」
  • 悪意ある行為から利用者を守る為の「証明書の信頼関係に関する制限」
  • 良く自動化された検証機能を持つアプリケーション
といったことに現れています

くらいで訳したらいいんでしょうか???
何か日本語になっていない気もしますが

『RFC 5280 に従って最低限「認証局の証明書の管理」をきちんとして、
証明書に書かれた様々な制限や証明書が信頼できるものかどうかの確認手順を守る
ちゃんと作られたアプリケーションを使うということ』
を RFC 5280 は利用者に「望んでいる」、と読むと良いのかもしれません

4 節では証明書に記される用途の制限に関して沢山の記述があります
例えば「発行された証明書まででそれ以降は信頼の階層は伸ばしてはいけない」
ということが記されていたりします
また 6 節では証明書が信頼に足るか否かの判定法に充てられています

ん〜、何か未消化、英語が辛いです
posted by OJH at 02:26| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年11月27日

サイドチャネル攻撃ってのが凄いなと思った

先日、IPA の暗号フォーラム 2008 を見てきました
不勉強で今回始めて知ったのですが
サイドチャネル攻撃という方法があるのだというのを知りました

暗号への攻撃というとアルゴリズムの隙をついたものが多く
総当たりするか、その数を減らす為にアルゴリズムの隙を狙うくらい?
と思っていたのですが「実装の隙を狙う」という方法が現実的になってるそうです

どんなデータを用いるかというと、
  • 処理時間
や、組み込み系だと
  • 消費電力
  • 電磁波
などを計測してパターンを見付けると総当たりすべき範囲が絞れてしまう!!
OpenSSL の場合処理時間が知られないよう返事をするタイミングを操作してるそうです
RSA/DES/AES などでそれぞれ方法があるらしいのですが
デモで実際に取得した電磁波のデータから秘密鍵を復元するデモを見せてくれました
http://www.rcis.aist.go.jp/special/SASEBO/index-ja.html

コンセントを通じて CPU のアナログノイズなんかも観測できるという話で
そこまで考えるとちょっと大変だなぁと思うのですが
近い将来その辺りのことまで考えないといけなくなるのでしょうか
SUICA や PASMO の改札の近くでアンテナを立てておけば
ズラズラと偽造用のデータが流れるとかいうんだと怖いですねぇ

そういえば
とかもっと昔には
なんて記事もありましたけど、やぁ、どうしよう
あ、これはちょっと違うな
posted by OJH at 02:41| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2008年11月26日

RFC 5280 の 2.2. Acceptability Criteria

既にタイトルの意味が取れなくなっているので IPA にお伺いを立てたところ
http://www.ipa.go.jp/security/rfc/RFC5280-02JA.html#022
「受容性クライテリア」ってやっぱり分かりませんでした
「許せる基準」とか? 英辞郎だと「判定基準」って出てきました
http://eow.alc.co.jp/acceptability+criterion/

RFC 5280 はインターネット上で「誰なのか」「何ができるのか」といった
色々な判定がスムースに進むように取り決めをしようということのようです

イントロでは既に出ていたのですが本文でも
"Internet Public Key Infrastructure" という単語が出てきました。
RFC 5280 はインターネットで PKI をスムースに運用する為の約束事集でしたが、
ではそのインターネット PKI の目的とは何ぞや? というと
「それに従っていれば誰でも一意に・自動的に
  • identification → 本人確認
  • authentication → 認証
  • access control → アクセスコントロール
  • authorization → 権限付与
という機能が運用できるルールを提供すること」かな?

identification, authentication, access control, authorization って何?
ちょっと怪しいと思うけど説明

identification:
これは自分が知っている人かどうかを確認することです
パスワードは「事前に知らされているパスワードを知ってる人かどうか」を
署名は「事前に知らされている公開鍵に対応する秘密鍵を持ってる人かどうか」を
確認することで「自分が知ってる人」=「本人」であることを確認します
でも、その本人がどんな人かまでは言及しません
家の鍵は「その家に入れる人かどうか」を確認するだけなので
鍵が盗まれてしまうと家の持ち主でなくても家に入れてしまいます

authentication:
これはその人が誰であるかということを確認します
SSL サーバー証明書には「サーバー名」に対応した「サーバーの運営者の住所や組織名」
免許証やパスポートには「顔写真」に対応した「氏名・住所」などが書かれており
第三者に対して自分が何者であるかを証明しようとします
サーバーの場合は FQDN を用いてアクセスすることで
免許の場合は顔と写真を照合することによって
認証の対象が記載されてるサーバー・人と対応することが確認できます

access control:
ネットワーク上には様々な対象が置かれています
ファイルや「プリンタ」だったりファイルにしても「データ」「プログラム」など
「コンピュータ」自体も置かれています
これらのものに「読む」「書き込む」「追記」「消去」「印刷命令」「実行」など
様々なアクセスが用意されていますが
誰が何にアクセスできるか? ということを管理することです

authorization:
鍵を持っていたり証明書を発行してもらっていることで
identification や authentication を通過したことによって
様々な対象にアクセスする権利を付与されるように
何かしらの権限を与えることです

X.509 という証明書の仕組みに更に仕様を重ねることで
インターネット上で上記機能の運用を円滑に進められるようにするのが
RFC 5280 の目的です

その為には、証明書で認証したい対象の情報以外にも、
その証明書の利用範囲や正当性を確認する為の情報など、
様々な事柄を決めなくてはいけないので決めていくことになります
posted by OJH at 01:59| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年11月24日

RFC 5280 の 2.1. Communication and Topology

"Communication and Topology" = 「通信と接続形態」って辺りでしょうか
インターネットへの接続環境に関しては特定の形態は想定していません
高速常時接続な人達ばかりではないので
メールを読むのに 1 日 1 回アナログモデムで接続するような方々にも
セキュアーな環境を提供すべく RFC 5280 は書かれています
また、証明書や失効リストの配布方法に関しても特に指定しないそうです

日本では既に FTTH が ADSL を契約者数では抜いているらしいですが
ブロードバンド回線事業者の加入件数調査 (08年9月末時点)
どっちにしろ定額常時接続はとても普及しています
一方で未だブロードバンド環境が得られない地域も多いらしく
衛星ブロードバンド普及推進協議会なんて方々もいらっしゃったりします
まだアナログダイアルアップ接続な方々も多くいらっしゃるのかと
モバイル環境も都市部では随分と整ってきていますが地方はまだまだですね

世界で見ると世界情報通信事情などに統計データが
ちょっとデータが古いかな? もっと新しいものも公表されてるかもしれません
世界家庭へのブロードバンド普及率,2012年に25%へ
まだまだ Google ショック? YouTube ショック? を体験してない人々が沢山います

「ディレクトリ」というのは「住所録」とか「名簿」といった意味があります
http://ja.wikipedia.org/wiki/ディレクトリ・サービス
コンピュータをいじってると色々なもののリストを管理しないといけません
コンピュータ・ホスト名・ユーザー・パスワードなど
ネットワーク上の資源を管理するデータベースのことを「ディレクトリ」と言います
例えば DNS ではホスト名などを階層的に管理しています
証明書には住所などが記述されておりディレクトリ・システムの一部を成しています

X.509 は ITU-T の X.500 番台の一部を成していまして
X.500 番台というのはディレクトリ・システムの標準を勧告しています
例えば DAP (Directory Access Protocol) というプロトコルが定義されてますが
これを簡単にしたのが LDAP (Lightweight Directory Access Protocol) です
X.500 番台や LDAP という仕組みがあるわけですが
RFC 5280 ではそれらに縛られずに証明書・失効リストを扱っていきます
ラベル:RFC5280
posted by OJH at 22:26| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

RFC 5280 の 2. Requirements and Assumptions の最初

第 2 節では RFC 5280 の対象を記述してます
大体どんなことが書いてあるかというと段落毎に
  • インターネットで X.509 を使うソフトを開発・運用する人は読んでね
  • 書いてないものを追加したり置き換えたりしても怒らないよ
  • 法律とか従うべきことが他にあったらそっちを見てね
  • 他に特化した文章が用意されてる X.509 の用途に関してはそっちを見てね
ということ

RFC 5280 はインターネット向けの X.509 の使い方を決めようとしていました
想定される使われ方は
  • WWW → HTTPS (SSL/TLS) によるサーバー認証やクライアント認証
  • メール → S/MIME で暗号化や送信の否認防止、SMTP/POP/IMAP サーバ認証・暗号化
  • ユーザー認証 → USB トークンや Java カードなどの IC カードなどなど?
  • IPSec → VPN の拠点同士の認証
これらに関するソフトを開発する人や相互運用する人達が
X.509 を読んで「ここどうする?」って悩まないように色々と決めていきます

「認証」ってのは「本人であるか」とか「誰であるか」ということを確認すること
SSL のサーバー証明書ならそのサーバの DNS 名や FQDN といったものが
個人やメールでの認証の場合にはメールアドレス等が認証されることになりますが
じゃぁ IP アドレスはいいの? とか個人はメールアドレスでしか認証できないの? とか
実際に認証を扱うソフトを作り始めると決めなくてはいけないことだらけです
「少なくともこれくらいできると便利ですよ」という指針は助かります

もちろん環境や要件によってより多くの仕様を決めなくてはいけなかったり
仕様を変更する必要は出てくると思うのでその場合は変えることを止めたりしません
飽くまで RFC 5280 は「ここどうする?」ってときに「こうしとこう!」という提案
グループウェアで個人認証に証明書使うけど社員番号を証明書に追記してもいいかな?
なんてことは悩まずに追記しちゃって OK ってことかな

ただ、何してもいいってもんじゃなくって、
証明書を認証局に発行してもらう場合は認証局の決めたことは守らないといけないので
その辺りの法律的な決まりや義務なんかに関しては何も言及しません

また、用途によっては RFC 5280 の守備範囲外のものもあって
"supplemental authorization" や "attribute management" という用途もあるらしい
"supplemental authorization" って何だ?? "attribute management" に関しては
例としては Attribute Certificate (属性証明書) が挙げられていますが
"An Internet Attribute Certificate Profile for Authorization"
RFC 3281 http://www.ietf.org/rfc/rfc3281.txt
があるのでそれぞれ特化した仕様などがあれば見てね、ってことかな?
ラベル:RFC5280
posted by OJH at 02:07| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年11月23日

OpenSSL が FIPS 140-2 取得

http://www.openssl.org/ にて openssl-fips-1.2.tar.gz がリリースされてますが
これは FIPS 140-2 を取得してのもののようです
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2008.htm

以前の取得状況も
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2006.htm
に書かれています

で、少し調べてみたんですがこの辺りを見ると最初に取得するまでには大変な苦労があったみたいです

FIPS 140 は Federal Information Processing Standards Publication 140
米国政府の暗号モジュール検証基準で検証証明書を貰うと政府に調達してもらえます
Open Source Software で検証してもらったのは始めてだったみたいで
Open Source であるからには様々な環境でコンパイルされる可能性があり
その辺も含めて積極的に検証してもらったなど上のリンクで OSSI の人が言ってます

なので、Open Source ということで検証が遅れたということもあるけど
幾つかのメーカーからの妨害もあったなんてことが書いてあるけどどうなんだろう?
SourceForge は OSS 寄りなこと言うんじゃないかしら? と疑ってみたり

まぁ、何はともあれ現在ではスムースに検証されているのか
アップデートされて検証されて証明書が発行されるという
順調なサイクルが回っているみたいです

OpenSSL には普段からお世話になっているので
今後もガンガンがんばって欲しいなと思っています
posted by OJH at 00:45| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする

2008年11月22日

RFC 5280 の 1. Introduction

RFC 5280 の目的と構成が説明されてます
最初の 1 文は
This specification is one part of a family of standards for the X.509
Public Key Infrastructure (PKI) for the Internet.
X.509 は、ITU-T が出してる「勧告 (Recommendations)」の 1 つ
http://www.itu.int/rec/T-REC-X.509-200508-I
中身は PKI という仕組みの実装を標準化しようとしている、みたい
証明書はどんなバイト列で表現するか、とかまで書いてある、みたい
ITU (International Telecommunication Union) は国連の専門機関
ITU-T はその「電気通信標準化部門 (Telecommunication Standardization Sector)」

PKI = Public Key Infrastructure (公開鍵暗号による社会基盤) は
説明しようと思うだけでお腹痛くなってくるのでリンクを貼って濁そう
5分で絶対に分かるPKI
デジタル世界の判子ができると契約とかできて素敵だネ!!という話です

RFC 3280 や RFC 5280 でやろうとしてるのは
「X.509 による PKI の実装をのうち証明書と証明書失効リストの部分に関してインターネットに合わせて詳細を詰めたりしよう」
ということなんだと現状理解してます

で、イントロの後何が語られるかが説明してあります
Section 2: インターネット上で PKI に望まれること
Section 3: インターネット上の PKI モデルの説明と過去のモデルとの関係
Section 4: X.509 の電子証明書のこと
Section 5: X.509 の電子証明書失効リストのこと
Section 6: 証明書の正当性を確かめる方法のこと

7, 8, 9 に関して直接言及が無いのは何故だろう?
Section 7: 証明書の内容が国際化されたのでその場合の比較方法?
Section 8: 運用上の考えるべきセキュリティーに関して?
Section 9: IANA の OID (Object Identifier) のこと?
Section 10: 謝辞
が書かれてる気がするけどまぁ読み進めれば分かるかな

更に Appendix として
Appendix A: 証明書などの構造の実装を ASN.1 で記述
Appendix B: Appendix A で用いた ANS.1 の記述方法などの注意点
Appendix C: 具体的な証明書・失効リストの中身
があります、と書かれています

最後に RFC 3280 の改訂版ということで RCF 3280 との違いについて述べられてます
  • 証明書の国際化の標準化と付随して検証のこと、古い証明書への対応
  • 個別の Extension に関して変更点
  • セキュリティーで考えるべきところが増えている
X.509 も RFC 3280 も、眺めてみたことしか無いので個人としては気にしない

イントロで 1 回潰しましたが
つづく
posted by OJH at 04:13| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年11月21日

暗号の2010年問題

RSAセキュリティ株式会社さんが
「暗号の2010年問題」に関して説明会をしたそうです。
データの受け手にも配慮を: 暗号の2010年問題――「運用見直しが迫る」とRSA
暗号の2010年問題 - RSAセキュリティが動向と課題を解説
もう避けられない? 暗号の2010年問題
間近に迫る「暗号の2010年問題」、企業が取るべき対応は?−RSAセキュリティ

2010年問題というと医療・薬品業界の方が有名かもしれませんが
暗号業界でも常用すべき暗号の鍵長等の更新時期として注目されてます
そんなの直ぐ変えたらいいじゃない! って思うわけですが
皆が一斉に変えないと結局皆が使える一番弱い鍵を使うことになったり
中途半端に環境が更新されたのではデータのやりとりができなくなるかも

特に組み込み系のものを変更するのにはコストが掛かりますし
携帯なんかでも RSA 暗号の鍵長が 1024 bit までのものが多いらしく
携帯で買い物をするときに SSL で暗号化されている通信経路が
使えなくなっちゃうと買い物もログインもできないってことになるかも

で、更に、日本国内と海外で移行時期にずれがあるみたいで
日本のユーザーが海外に接続できないなんてことが起きたりするかも
って懸念してる人もいるみたいです

どんなことでも移行って面倒だし大変ですよね
季節の変わり目なんて「今日何着る?」って悩みっぱなしです
ラベル:暗号 RSA ssl
posted by OJH at 11:41| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする

2008年11月20日

RFC 5280 でも読んでみようかと思った

セキュリティーな仕事をしていると色々なものが複雑に絡まっていて、
概念を理解することからして困難なことが多いです。
更にはそれらを組み合わさったシステムを作れいじれと言われると、
どこから理解したら良いのか分からなくなってしまいます。

そこで日頃から気を抜いてしまうと原理主義になってしまう欠点と
1 つのことが長続きしないという長所を補うべく、
原書にあたりながら思ったことを記すことを続けたならば
素敵な大人になれるに違いないと思ったのがきっかけ。

とりあえずで選んでみた題材は RFC 5280:
http://www.ietf.org/rfc/rfc5280.txt
http://www.ipa.go.jp/security/rfc/RFC5280-00JA.html
これはインターネットにおける電子証明書の使い方が書かれています。
Category が Standards Track (標準化過程) だそうです。
証明書に関しては RFC 3280
http://www.ietf.org/rfc/rfc3280.txt
がありますが RFC 3280bis を経て改訂された感じになっている、のかな?
3280 からの主な変更点は国際化と付随する文字列比較だとか。

ちなみに RFC (Request for Comments) は
IETF (Internet Engineering Task Force) って標準化団体が
皆で議論して基本的にはプロトコルとかの標準化を目指して公表する文章で、
基本的というのはたまにジョークなものも入っているから

Abstract には
X.509 version 3 の電子証明書フォーマットのこと
X.509 version 2 の電子証明書失効リストのこと
X.509 証明書の階層のチェックの方法 (アルゴリズム)
ASN.1 の定義と具体的な証明書の例

なんかが書いてあるよ、と書いてあります

さて、中学で止まっている英語力でどこまで読み進められるか?
それとも読み終わる前に和訳が出てそちらに逃げてしまうのか?
続きを読む
posted by OJH at 20:56| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする
×

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