2017-02-27

電子署名のSHA-1衝突(SHAttered)問題への対応  [by miyachi]

SHA-1ハッシュアルゴリズムの危殆化はずいぶん前から叫ばれてきましたが、とうとうSHA-1衝突問題(SHAtteredと呼ばれる)が、2月23日にGoogleとオランダのCWI研究から公開されました。ここではハッシュ値が同じで異なるPDFファイルも公開されており、90日後に手法を公開すると予告されました。

比較的詳しいニュースとしてはGigaZineで、参考になるスライドがサイボウズの社内勉強会のスライドとして公開されています。詳しくはこちらをご覧ください。

GigaZine:
Googleがハッシュ関数「SHA-1」を破ることに成功、90日後に手法を公開予定

サイボウズの暗号とセキュリティ社内勉強会用スライド:
GoogleのSHA-1のはなし

ここではSHAttered問題の解説では無く、特にドキュメントやデータに対する電子署名についての状況と考えられる対応を簡単にまとめます。
[続きを読む]
2017-02-27 15:44:24 - miyachi - コメントを書く - [PKI/暗号] - この投稿をtweetする!

2015-04-07

トラスト・セキュリティ  [by miyachi]

電子署名関連製品を開発して、JNSAの電子署名WGで活動しています。ところでこの「電子署名」と言う言葉が「古い」「目新しさが無い」等と言われて久しく、「電子署名終わっているよね?」みたいな言い方をされる事もあります…困ったものです(^^;

まあ確かに「電子署名」と言えば電子文書やデータに対するイメージもあって応用もしにくいですね。と言うことで「電子署名」も含んだ新しい言葉を考えてみました。それは「トラスト・セキュリティ」です。Google先生で検索してみると意外に先にこの言葉を使っている人はいないみたい??ただ警備系の会社名では結構使われていそう…ま、まあとりあえず公知にしとくかってことでSlideShareに上げてみました。



この言葉自体を今後使うかどうかは別にしてIoTも含めてトラストを守るセキュリティ分野に活動の幅は広げて行こうと考えています。さてどうなりますかw
2015-04-07 15:35:13 - miyachi - コメントを書く - [PKI/暗号] - この投稿をtweetする!

2014-04-02

なんとなく分かった気になるPDF電子署名仕様入門2  [by miyachi]

新年度になりましたので昨年度の資料を整理していてそう言えばこの資料は公開していなかったなぁ…と言う事で公開します。JNSA電子署名WGのスキルアップTF勉強会ネタとして10月に行った「なんとなく分かった気になるPDF電子署名仕様入門2」です。以下よりダウンロードください。

なんとなく分かった気になるPDF電子署名仕様入門2
http://www.langedge.jp/download/jnsa/20131030-SUTF-4-pdfsign.pdf

開発者や仕様策定者向けですので一般向けの内容ではありません。PDF電子署名はPDF内部知識と電子署名の知識と両方が必要なのですがPDFの知識はなかなかPKI技術者には敷居が高いようで皆さんの要望を受けて行った勉強会の資料です。とは言え全部を説明するのは難しいので「なんとなく分かった気になる」としています。PDF電子署名にご興味があればご笑覧ください。
2014-04-02 17:00:28 - miyachi - コメントを書く - [PKI/暗号] - この投稿をtweetする!

2014-03-31

1~3月の発表  [by miyachi]

ああ。3月も終わります。正月以降にBlog更新していません…orz いやネタは溜まっているのですが。と言う事でまず簡単なネタと言う事で1月以降に発表した内容を整理しておきます。

1)2014年1月29日:Network Security Forum 2014

JNSA電子署名WGで50分時間を貰えたのでミニパネルのパネラーの一人として発表しました。とは言え時間が短いので実質10分程度の発表です。資料は以下になります。420KB程度ありますのでご注意を。内容としては1年間の活動成果を簡単にまとめて今後活動の説明となっています。海外動向等も電子署名WGの皆さんが発表されています。

ミニパネル 電子署名をめぐる国内外の最新動向
「電子署名の今後に向けて」~スキルアップTFの活動から~
http://www.jnsa.org/seminar/nsf/2014/data/NSF2014_A2-4_miyachi.pdf

2)2014年2月4日:ITフォーラム2014
こちらはAITCクラウド・テクノロジー活用部会からの発表です。気象庁XML(気象庁防災情報XMLフォーマット)と言うオープンデータをネタにメンバーで発表しており、私はセキュリティの可能性についてまとめて発表しました。こちらも短く15分程度の発表でした。資料は公開されていないのでこっそり以下に公開しましたのでご笑覧ください。1.2MBくらいあります。

気象庁XML等のオープンデータにおける電子署名とタイムスタンプの活用アイデア
http://www.langedge.jp/download/aitc/LE-opendata-sign-20140204.pdf

3)2014年3月13日:PKI Day 2014
JNSA電子署名WGとしての発表です。う~む私がPKI Dayで発表する日が来るなんて(^^; 恐れ多い事ですが時間も2人(亀田さんと)で1時間以上貰ったのでクラウド署名等について濃く話が出来たかなと思っています。「非PKI署名」なんてタイトルに入っているので「PKI Dayに非PKIなんて!」とかなりあちこちからツッコまれましたw 1.4MBくらいあります。

新しい電子署名 ~クラウド/モバイル署名と非PKI署名~
http://www.jnsa.org/seminar/pki-day/2014/data/PM02-1_miyachi.pdf

以上3イベントに参加発表しました。話をしているうちにだんだん自分の考えも整理できてくるのでやはりこういうチャンスを頂けるのはありがたいですね。次は電子署名WGの活動報告もまとめたいと考えています。時間が無い~(^^;
2014-03-31 20:36:12 - miyachi - コメントを書く - [PKI/暗号] - この投稿をtweetする!

2013-06-28

.NETのRSACryptoServiceProviderの実行速度低下  [by miyachi]

久しぶりのPKIプログラミングネタです。Windowsでは電子署名をするのにCAPIや.NET等の幾つかのAPIが用意されています。そのうち.NETのRSACryptoServiceProviderにおいて SignData() と VerifyData() のメソッド、つまりRSA署名とRSA検証のAPIの実行速度が遅くなると言う問題が見つかりました。

 Problem: Delay while calling RSACryptoServiceProvider SignData or VerifyData methods

最初はアクティブディレクトリ認証(以後AD認証)が必要なサーバでのみ速度が遅く、LDAP通信が頻発していると言う事でした。どこでLDAP通信されているのか分からずテストプログラムを作成して試して頂きました。Windows証明書ストアへのアクセスにAD認証が必要なのではと予想したのですがハズレでした。結局RSA検証している箇所が遅くRSA検証を.NETからOpenSSLに変更したところLDAP通信が無くなったのでした。

そこからS社のMさんが見つけたのが上記リンクのページです(Mさんありがとうございました)。確かにこれに該当していたようです。RSAクラスにはハッシュアルゴリズムが指定可能であり、昨今ではSHA-2も指定する必要があります。デフォルトのSHA-1以外のハッシュアルゴリズムを利用した時にドメインコントローラに問合せに行ってしまうとのこと。回避方法はデフォルト(SHA-1)でやれ…って現在ではもう無理です(^^; と言うことでこういう事もあろうかと用意していたOpenSSLを使って全く同じ処理をするモジュールに切り替えて問題解決したのでした。

RSA検証はこれで良いのですがRSA署名にWindows証明書ストアの秘密鍵を使う場合にはOpenSSLでは対応できないのでWindowsのAPIを使わざるを得ません。1つ可能性があるのは古いCAPIのAPIを使えばこの問題が生じないのでは無いかと言う事なのですが…まだチェックしていません。追加で何か分かったら書き足します。

何はともあれ .NETRSA署名ドメインコントローラ利用環境 で使った場合には通信のオーバーヘッドによる速度低下があると言う情報を残します。と言ってもこの情報を必要としている人はほとんどいないかも(^^;;;
2013-06-28 12:17:26 - miyachi - コメントを書く - [PKI/暗号] - この投稿をtweetする!

2013-05-24

JNSAやPAdESなどなど  [by miyachi]

最近はFaceBookばかり書いていてブログがおろそかになっていてすみません。最近の出来事や書いた資料等を簡単にまとめます。

JNSA電子署名ワーキンググループ発足

JNSAの標準化部会に新しく作られる電子署名WGの活動が開始されました。まず4月24日に説明会があり、5月23日に第1回目のWGが開かれました。うちのような電子署名系ベンダーはもちろん認証局やタイムスタンプ局の皆さんも参加されてバランスが良いワーキングになったように感じました。残るはユーザ系の企業が入ってくれればと言うところですが、ユーザ系企業の人を呼んできてお話を聞くことはできそうです。かつてのECOM時代には及びませんが良い感じのスタートが切れたのではないでしょうか。ちなみに電子署名WGの下で活動するTF(タスクフォース)は今のところ以下の3つです。
 署名検証-TF
TBFで昨年度行ってきた活動をJNSAで継続。検証手順の標準化は実はありません。検証が必要な項目や内容を整理して標準化を目指します。

 PAdES-TF
PDFの長期署名であるPAdESの標準化活動。PAdES仕様について問題点の確認やプロファイル作成を目指します。

 スキルアップ-TF(仮称)
唯一標準化では無く参加者のスキルアップや教育の場を提供します。メンバーの興味がある内容について講師を設定して説明して貰います。オープンソースの長期署名ライブラリFreeXAdES開発と勉強会を実施予定。
私は全部参加することになりますが特にスキルアップTFはメイン担当になりそうです。ご興味があればご一緒にいかがですか?

PDFインフラストラクチャ解説 0.30版公開

情報化社会のインフラとなったPDFの解説本が0.30版になりました。アンテナハウスのCAS-UBを使った電子書籍として公開されています。0.30版では私の方でPAdESの説明を書きました。フリーダウンロード可能ですのでPDFやPAdESのご興味があれば是非ご覧ください。

Acrobat-XIでPAdESファイルを作成する

JNSAの電子署名WG説明会で簡単に説明した資料を公開しています。最新のAcrobat-XIを使ってPAdESのLTV対応のファイルを作成する方法を説明しています。こちらからダウンロード。PDFファイルへのリンクですのでご注意ください。
2013-05-24 15:04:08 - miyachi - コメントを書く - [PKI/暗号] - この投稿をtweetする!

2013-04-05

Adobe Reader / Acrobat のWindows証明書ストア利用設定方法  [by miyachi]

Adobe Reader や Acrobat で電子署名を使う場合にまず設定して欲しいのが「Windows証明書ストア利用設定」です。以前本ブログでも書いたことがあるのですが、Acrobat-XIでは設定方法も変更されているので一度きちんとまとめておきます。なお同じ内容をPDFファイルにしましたので、よろしければダウンロードして再配布等自由にお使いください。 [続きを読む]
2013-04-05 15:35:45 - miyachi - コメントを書く - [PKI/暗号] - この投稿をtweetする!

2012-10-10

商業登記証明書の新ルート証明書  [by miyachi]

毎年10月10日になると商業登記証明書新しいルート証明書が有効になります。これだけなら大したことは無いように思うかもしれませんがPDF電子署名ではちょっと困った問題を生じます。昨日まで有効だった商業登記証明書で署名したPDFをAcrobatかReaderで開くと以下のような画面となり検証結果が「不明」となります。





これは失効確認に利用するOCSPの署名が新しいルート証明書に切り替わった為に、署名証明書のルート証明書と一致しない為です。これを防ぐ為には別ルート証明書でも信頼するルート証明書であれば良いとか、より正確にはリンク証明書を使うとかすれば大丈夫です。ただAdobeのAcrobat/Readerがこれに対応することは無いのではないかと思います。困ったものですね。

Acorbat等では「不明」と表示されますがGPKIの証明書検証サーバ等では正常に検証されますので電子申請等に使う分には全く問題ありません。ただ代表印の代わりに民間同士の電子契約等で使う場合にはちょっと嫌ですね。

これを運用で防ぐには自社の商業登記証明書も同じく10月10日で新しいものに変えるくらいしか今のところ対応方法がありません。Adobeさん対応してくれませんかねぇ…

なお弊社のLE:XAdES:Libや今開発中のLE:PAdES:Libではリンク証明書等にも対応していますので正常に検証が可能です。

と言うことでPKI業界的には10月10日は商業登記証明書新ルート発行の日と言うことで(^^;
2012-10-10 23:24:23 - miyachi - コメントを書く - [PKI/暗号] - この投稿をtweetする!

2012-08-28

DRM=鍵管理なの?  [by miyachi]

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

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

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

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

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

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

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

GPKI/LGPKI/JPKI/HPKIのRSA2048/SHA2対応とは?  [by miyachi]

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

指摘:
「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:暗号アルゴリズム移行に伴うドキュメント追加について

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

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

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

2012-08-09

PKI用にOpenLDAPをWindows環境で使う その弐  [by miyachi]

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

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


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

 1)LGPKI(dir.lgpki.jp)にJPKI証明書の検索実行
 2)GPKI(dir.gpki.go.jp)を紹介される
 3)紹介されたGPKIにJPKI証明書の検索実行
 4)JPKI(ldap.jpki.go.jp)を紹介される
 5)紹介されたJPKIにJPKI証明書の検索実行
 6)情報取得成功!


ちなみに本来は ldap_set_option() で LDAP_OPT_REFERRALS をONにすると自動的に辿ってくれるはずで、WinLDAPは何もしなくても1)の結果6)が返ってきます。OpenLDAPでは何か私が間違っているのだと思いますが自動で辿ってくれなかったので、自分で辿っています。この辺りは時間があれば再調査していところですが… さてそれではソースコードです。エラー処理は入っていませんのでご注意ください。 [続きを読む]
2012-08-09 13:20:52 - miyachi - コメントを書く - [PKI/暗号] - この投稿をtweetする!

2012-08-08

PKI用にOpenLDAPをWindows環境で使う その壱  [by miyachi]

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 これから本文。本文はもっと長いです(^^; [続きを読む]
2012-08-08 20:15:35 - miyachi - コメントを書く - [PKI/暗号] - この投稿をtweetする!

2012-03-13

CryptoAPI(CAPI)によるRSA-SHA2署名  [by miyachi]

2011-04-25に「.NET FrameworkによるRSA-SHA2署名(完結編)」を投稿していましたが、ICカード対応でCryptoAPIでRSA-SHA2署名を実装する必要があり調査してみました。基本的には.NET Framework編と同じ理屈で動作したので、CryptoAPI(CAPI)対応編としてまとめます。

詳しくは.NET Framework編をお読み頂きたいのですが、暗号プロバイダとして標準のPROV_RSA_FULL(1)からSHA-2に対応したPROV_RSA_AES(24)に切り替える必要があります。

ではPROV_RSA_AESで証明書に関連付いた秘密鍵を使う方法をソースコードとして以下にまとめます。証明書(PCCERT_CONTEXT) pcCert は適当な方法で用意して下さい。また以下ではエラー判定は行なっていませんし開放もちゃんとやっていませんのでエッセンスのみと考えてご覧下さい。

// 秘密鍵に関連付いた証明書の取得
PCCERT_CONTEXT pcCert = MyFindCert(Thumbprint); // ダミーです

// 標準のプロバイダ(PROV_RSA_FULL)の取得
HCRYPTPROV hProv = NULL;
CryptAcquireContext(&hProv, NULL, NULL, PROV_RSA_FULL, NULL);

// 個人証明書ストアの取得
HCERTSTORE hStore = NULL;
hStore = CertOpenSystemStore(hProv, "MY");

// 証明書を個人証明書ストアから再取得
PCCERT_CONTEXT pcCert2;
pcCert2 = CertFindCertificateInStore(
hStore, X509_ASN_ENCODING|PKCS_7_ASN_ENCODING,
0, CERT_FIND_EXISTING, pcCert, NULL);
// 入れ替え
CertFreeCertificateContext(pcCert);
pcCert = pcCert2;

// 秘密鍵の取得
BOOL hasPrivateKey = FALSE;
DWORD dwKeySpec = 0;
BOOL callerFreeProv = FALSE;
hasPrivateKey = CryptAcquireCertificatePrivateKey(
pcCert, 0, NULL, &hProv, &dwKeySpec, &callerFreeProv);

// 秘密鍵の鍵プロバイダ情報のサイズ取得
PCRYPT_KEY_PROV_INFO pKeyProvInfo = NULL;
DWORD dwSize = 0;
CertGetCertificateContextProperty(
pcCert, CERT_KEY_PROV_INFO_PROP_ID, NULL, &dwSize);
pKeyProvInfo = (PCRYPT_KEY_PROV_INFO)HeapAlloc(
GetProcessHeap(), 0, dwSize);

// 秘密鍵の鍵プロバイダ情報の取得
CertGetCertificateContextProperty(
pcCert, CERT_KEY_PROV_INFO_PROP_ID, pCryptKeyProvInfo, &dwSize);

// RSA-SHA2対応のプロバイダ(PROV_RSA_AES)の取得
HCRYPTPROV hProv2 = NULL;
CryptAcquireContextW(
&hProv2, pKeyProvInfo->pwszContainerName, NULL, PROV_RSA_AES, 0);
CryptReleaseContext(hProv, 0);
hProv = hProv2;

// ハッシュ生成(SHA-256)
HCRYPTHASH hHash = NULL;
CryptCreateHash(hProv, CALG_SHA_256, 0, 0, &hHash);

// 署名対象のハッシュ計算(std::vector<unsigned char> dataが署名対象)
CryptHashData(hHash, &data[0], (DWORD)data.size(), 0);

// 署名値サイズの取得と領域確保
CryptSignHash(hHash, dwKeySpec, NULL, 0, NULL, &dwSize);
std::vector<unsigned char> pbData;
pbData.resize(dwSize);

// 署名値の計算
CryptSignHash(hHash, dwKeySpec, NULL, 0, &pbData[0], &dwSize);

色々余計なことをしているかもしれませんこれで動作しました。ちょっとソースが長くてすみません。やっぱり.NETの方が楽ですねw ポイントとしては普通にPROV_RSA_FULLの秘密鍵を取得して、そこから秘密鍵の鍵プロバイダ情報をCertGetCertificateContextProperty()で取得し、pwszContainerNameを使ってPROV_RSA_AESの暗号プロバイダハンドルを取得しています。

なおWindows XPではSP3以降が必須となりますのでご注意下さい。検索してもCAPIでRSA-SHA2署名の情報があまり無かったので参考になれば幸いです。それにしてもRSA-SHA2問題は2010年問題とも言われていましたがもう2012年ですね(^^;
2012-03-13 13:23:06 - miyachi - コメントを書く - [PKI/暗号] - この投稿をtweetする!

2012-02-13

商業登記電子認証ソフトによる商業登記証明書取得  [by miyachi]

「商業登記電子認証ソフト」が無償公開されているのは以前もブログで紹介していましたが、今回弊社の商業登記証明書を商業登記電子認証ソフトを使って取得してみました。

まず商業登記電子認証ソフトを確認したところ昨年末にVer1.1がリリースされていました。画面の修正等のようです。早速起動してみて派手なメニュー画面から「手順1:鍵ペアファイル及び証明書発行申請ファイルの作成」を選びます。右の画面が開かれますので必要項目を入力します。必要最低限になっているようでその点は使いやすそうです。ちなみに「商号又は名称の表音・略称等」には英語名は駄目だと以前言われました。あくまで表音なので会社名をローマ字で書けと…オプションなので私は省略です。ファイルの格納先はフォルダダイアログで指定しますが開く度に初期位置に戻るのは使い難いです。まぁサクサクと入力して下にある「鍵ペアファイル及び証明書発行申請ファイル作成実行」をクリックすればOKです。

出力ファイルを確認するとCD-Rに焼くための "SHINSEI" ファイルを確認します。と言っても中の確認は出来ないので存在確認だけですが。ちなみに1KB未満の小さなファイルです。これをCD-Rルートに焼いて法務局に持って行きます。後は "日時番号+鍵ペア" となっている鍵ペアファイルと "日時番号+申請書・委任状.pdf"を確認します。申請書のPDFファイルが出来るのは便利ですね。生年月日と請求する証明書の期間を入力すれば印紙を貼ってそのまま法務局の窓口に持って行けます。

と言うことでCD-Rを作成して申請書と代表印の印鑑カードの3点を持って法務局窓口へ。今回は24ヶ月の証明書にしたので印紙は15,100円でした。高いような安いような…(^^; 窓口に出すと特に問題なくシリアル番号が記載された「電子証明書発行確認表」が返されてきます。なおCD-Rは返してくれません。

事務所に戻って再度「商業登記電子認証ソフト」を起動します。メニュー画面から「手順3:電子証明書取得」を選択して「電子証明書発行確認表」に記載してあるシリアル番号と手順1で作成した鍵ペアファイルとパスワードを指定して、生成するPKCS#12用のパスワードを新規に指定して「電子証明書取得実行」ボタンをクリックすれば無事にPKCS#12形式の証明書+秘密鍵が入手出来ます。めでたし。

以前は有料のソフトが無いと駄目だったですしフロッピーディスクだけでしたが、無償ソフトとCD-RでOKになったので取得しやすくなりましたね。大企業では取得するのも大変だと思いますが中小零細企業なら取得も簡単だと思います。弊社の「図面XML署名ツール」による図面申請時等にも使えますし法人(正確には代表者)の公的な証明書として良いと思います。商業登記証明書ももっと使える場が増えると良いですね。
2012-02-13 17:23:23 - miyachi - コメントを書く - [PKI/暗号] - この投稿をtweetする!

2011-06-15

図面XML署名ツール (LeZumenSign) ネット販売開始  [by miyachi]

お待たせしました!図面XML署名ツールのリリースとネット販売を開始しました。購入(ネット販売)は図面XML署名ツールの製品ページから行えます。

図面XML署名ツールは、「不動産登記規則第73条第1項の規定により法務大臣が定める土地所在図等の作成方式」に規定されている、電子申請の為に土地所在図、地積測量図、建物図面及び各階平面図並びに地役権図面(これらを電子化したファイルを「図面情報ファイル」と呼びます)に対する電子署名を付与した結果である「図面署名ファイル」を生成する機能を提供します。

これまでベータユーザ様にてテストをして頂いており、7名の方にご提供してうち6名の方より、実際に不動産登記を行って問題無く登記完了したとのご報告を頂いています。特に使い方に迷うことも無かったとのことです。

個人の方が多いのかなと思っていましたが、法人様(例えば土地家屋調査士法人)や地方自治体の方にもベータ版を提供して幅広いニーズがあるのだと再認識しました。法人様ではPKCS#12形式のファイルで取得する商業登記証明書のご利用を頂いています。なお各証明書の取得は以下のブログをご覧下さい。

 個人の場合:公的個人認証サービス電子証明書の入手方法
 法人の場合:法務省の「商業登記電子認証ソフト」

また製品の使い方や証明書に関しても詳細は新たに公開した製品マニュアルをご覧下さい。

その他ご質問等何でもお気軽に担当の宮地宛にご連絡下さい。
2011-06-15 15:46:30 - miyachi - コメントを書く - [PKI/暗号] - この投稿をtweetする!