こちらもサイトリニューアルに伴ったご指摘です。

指摘：
「DRM(鍵管理)ってとこはDRM＝鍵管理と捉えられるとちょっとどうかと。」

回答：
これは [暗号化/DRMシステム] の内容についてのご指摘ですね。あれ？このご指摘は「PKI＝鍵管理」に関してなのかな？それは確かにおかしいと私も思います(^^; そこは直してみました。

一方「DRM＝鍵管理」に関してですが、DRM（Digital Rights Management）の定義は「デジタルコンテンツの著作権を保護して、その利用や複製を制御制限する技術」だと考えています。その意味で鍵管理とDRMはイコールでは無いだろうと言うのはご指摘の通りだと私も思います。この真意としては逆にDRMにおいて鍵管理以外の部分（例えばユーザ管理やコンテンツ管理や権限管理）は、既存の認証技術やデータベースやWebサービスで実現が可能であり、クライアント端末に保管する鍵がきちんと管理する部分が最も重要になると私的には考えているからです。

ちなみにDRMと同じような仕組みであってもオンラインで利用するコンテンツに対しては暗号化では無く「アクセス制御」で済むケースが多いです。例えば動画配信をするとして、クライアントPCに保存出来ないストリーム配信ならアクセス制御だけで良いですが、動画ファイルをダウンロードさせてオフラインでも利用する為にはDRMの仕組みが必要になります。その意味ではDRMはクライアントにおいてオフライン時に「利用を制限」する仕組みだと考えています。

DRMでは一般に暗号化されたコンテンツを復号して利用します。復号する為の鍵をどのように管理するかがDRMシステムのポイントとなります。従来のDRMの仕組みでは秘匿された鍵を利用していました。この秘匿している仕組みが分かってしまうと復号する為の鍵が取得出来てしまい不正利用が可能となってしまいます。しかし復号は必須である為に100％破れない仕組みは不可能となります。この為にDRMでは破られた場合の移行手段も考慮に入れるか、破られるリスクも含めてビジネスモデルを構築する必要があります。

このようにDRMの仕組みの中で一番クリティカルな箇所はクライアントでの鍵管理だと考えている為に一見すると「DRM＝鍵管理」的な説明になっていると思います。言い方を変えるとクライアントでの鍵管理さえきちんとできればDRMの他の部分は比較的容易に実現が可能と考えていると言うことです。できるだけ既存の技術で可能な範囲はそのまま利用すべきだと考えていますので、鍵管理の部分だけ提供すれば良いと考えています。以下余談となります。 [続きを読む]

サイトリニューアルに伴い電子署名系の情報が増えたのですが、私の書いた内容について指摘を幾つか頂いたのでブログで回答させて頂きます。

指摘：
「GPKI/LGPKI/JPKI/HPKIのRSA2048/SHA2対応という言い方は微妙ですね、SHA2対応するのはそれぞれの認証事業者なので、SHA2対応した証明書に対応可能、ってとこでしょうか。」

回答：
[ラング・エッジの電子署名への取り組み]の「RSA2048bit/SHA-2(256/384/512bit)への対応」に関するご指摘ですね。すみません分かり難く誤解を招く書き方だったかもしれません。

真意を少しまとめます。まず「RSA2048/SHA2対応」とは確かに狭義では「証明書（＋秘密鍵）のRSA2048/SHA2対応」だと理解しています。その意味では「SHA2対応するのはそれぞれの認証事業者」で間違い無いと思います。しかしながら実際に電子申請等のサービスを提供している運営側から見た場合には単に利用される証明書がSHA2対応しただけ…とは言えない事情があると考えています。利用しているライブラリや自サービスの為に構築したシステムで使われているソフトウェアが全て「RSA2048/SHA2対応」になる必要があります。特にGPKI/LGPKIでは移行指針を示して具体的に運用に必要な内容がまとめられています。以下を参照しています。

　・GPKI：相互運用性仕様書
　・LGPKI：暗号アルゴリズム移行に伴うドキュメント追加について

スケジュール的に現在は「新旧両暗号に対応・現行の暗号を利用（フェーズ１）」にあたります。平成２６年度より「新旧両暗号を利用（フェーズ２）」となり、最終的には「新たな暗号のみ利用（フェーズ３）」となります。平成２５年度末までには新暗号（RSA2048/SHA2）への対応を完了させる必要があります。

では技術的に見て新暗号（RSA2048/SHA2）対応するのに必要なポイントとしては、証明書検証サーバやリポジトリ（ディレクトリサーバ）が新旧あったり、ICカードを利用した署名プラグインの更新があったり、もちろん中の暗号ライブラリも含めて新暗号（RSA2048/SHA2）対応する必用があると言うことになると考えています。単純に証明書が新暗号（RSA2048/SHA2）対応すれば良いと言うのとは少し違った面で作業が必要になると考えています。

つまり私の真意としては少し広く捉えると言うか運営側から見て必要となる全てのソフトウェアのアップデートへの対応が弊社にて可能だと言う事を言いたかったと言うことになります。弊社はソフトウェアベンダーなので運営側からの見方になってしまっていると思います。いえそれ以前に私がきちんとまだPKIを理解していないと言う面ももちろんあると思います。不足しているのは勉強して行き訂正して行ければと考えていますのでこれからもご指摘よろしくお願い致します。以下は少し補足と言うか余談的な話になります。 [続きを読む]

「その壱」では主にOpenLDAPのバイナリの入手等について書きましたが、今回はプログラミング編です。PKIのプログラミングではLDAPのディレクトリサーバから証明書やCRLを取得する必要に迫られます。Windows環境ならCryptoAPIでも可能ですが、マルチプラットホームを考えるとOpenLDAPを使った方が良いですよね。ちなみにWinLDAPとOpenLDAPはAPI的にはほぼ同じです。微妙な違いや動作に違いがありますがそれは今回説明する予定です。LDAPクライアントとして情報を取得する手順は大きく言って以下の４つです。

　① 初期化：ホスト指定等の初期設定
　② 検索実行：問合せを実行し紹介(Referral)があれば対応
　③ 情報取得：成功したら必用な情報を取得
　④ 後処理：確保したリソースを開放

紹介(Referral)とは、相互運用されているPKIドメインで自ドメイン以外の検索要求があった場合に、情報を持っているであろうディレクトリサーバを紹介されるケースです。例えばJPKIの証明書をLGPKIのディレクトリサーバに要求すると以下のようになります。

　１）LGPKI(dir.lgpki.jp)にJPKI証明書の検索実行
　２）GPKI(dir.gpki.go.jp)を紹介される
　３）紹介されたGPKIにJPKI証明書の検索実行
　４）JPKI(ldap.jpki.go.jp)を紹介される
　５）紹介されたJPKIにJPKI証明書の検索実行
　６）情報取得成功！

ちなみに本来は ldap_set_option() で LDAP_OPT_REFERRALS をONにすると自動的に辿ってくれるはずで、WinLDAPは何もしなくても１）の結果６）が返ってきます。OpenLDAPでは何か私が間違っているのだと思いますが自動で辿ってくれなかったので、自分で辿っています。この辺りは時間があれば再調査していところですが… さてそれではソースコードです。エラー処理は入っていませんのでご注意ください。 [続きを読む]

PKIの世界ではCRLや証明書はLDAPのディレクトリサーバから取得することが多いです。特に日本のGPKI/LGPKI/JPKI等の相互認証しているPKIドメインだとディレクトリサーバも公開されていますし、使わなければ損な状況でもあります。

なお余談ですがLDAPのポート番号はldap:389/ldaps:636となっていて、企業内からだとファイアーウォールで許可されていないケースも多いです。この為にPKI現場のSEの皆さんにはLDAPは結構不評だったりするのですが…(^^;

閑話休題。Windows環境でクライアントとしてLDAPを使うAPIとしてWinLDAPが提供されています。これまで私もWinLDAPを使ってきたのですが、最近どうも調子が悪い…と言うよりも実行に時間がかかるようになっていることを発見。Windows XP環境だとあっという間に完了する検索が、Windows 7環境だと秒単位でかかります。

LDAPはCAPI(CryptoAPI)のCryptRetrieveObjectByUrl()でも取得可能です。なおここにCAPIを使ったCRLの取得について説明があるので参考になります。でもCAPIのAPIを使ってもWindows 7環境ではやはり秒単位の時間がかかります。内部的には同じAPIを呼んでいる気がします。

しかしながら遅くなった理由が全く解せない。とは言えある案件で時間も無かったので解析するよりもOpenLDAPを使ってみようと思い立ちました。とここまでが長い前振りでしたw これから本文。本文はもっと長いです(^^; [続きを読む]