新型コロナの影響で業務の電子化の推進が加速しています。電子署名もあちこちから注目を集めるようになって来て色々な電子署名サービスも出てきました。PKIと公開鍵暗号を使ったデジタル署名が主流でしたが他の方法もあります。デジタル署名は電子署名の1種ですが他の電子署名もあると言うことですね。昔から電子署名に関わって来た技術者から見ると正直言って現状は玉石混交です。でも電子署名サービスを判断する基準が今はありません。電子認証の世界ではNIST SP 800-63-3で認証保証レベルが規定され、米国以外（日本）でも使われています。と言うことで同じように署名保証レベルを決められないかと考えて見て案が出来ましたので公開します。これはまだ弊社案（ラング・エッジ案）となります。

その前にNIST SP 800-63-3を簡単に振り返ってみます。なお日本語訳がJIPDECで公開されていますので、詳しくはそちらを見てください。認証保証レベルは3つの項目に分かれています。IAL（Identity Assurance Level）、AAL（Authenticator Assurance Level）、FAL（Federation Assurance Level）です。IALが本人確認、AALが認証手段、FALが連携手段に関するレベルと言えます。これに対して電子署名の場合には、署名本人確認レベル、署名技術手段レベル、署名運用監査レベルの3つの保証レベルに分けることを提案します。

署名本人保証レベル：SIAL Signature Identity Assurance Level	署名者の本人性をどうやって確認したか
署名方法保証レベル：SMAL Signature Method Assurance Level	電子署名をどのような方法で保証するか
署名運用保証レベル：SPAL Signature Policy Assurance Level	署名サービスの運用や監査のレベル

色々なレベルが考えられると思いますがまずはこれだけあればかなり電子署名サービスの特長は掴めると考えています。 [続きを読む]

だいたい11月後半で商業登記証明書のルート証明書が更新されます。更新されると古い商業登記証明書では「有効期間内」でもAdobe Reader/Acrobatの検証結果が「不明（INDETERMINATE）」になってしまいます。これを運用で避ける為に毎年11月末か12月初旬に商業登記証明書を更新しています。あまり電子署名に詳しく無い方の場合には「商業登記証明書は毎年12月に取得する」ことをお勧めします。有効期間も24ヵ月あっても無駄になるので15ヵ月で良いと思います。今年も本日更新の申請に行ってきました。

閑話休題。商業登記証明書は当然商業登記の内容を証明してくれるものですが、現在商業登記では日本名や住所しか登録していません。商業登記証明書には「商号又は名称の表音・略称等」と言うオプションの登録項目があります。過去にそこに弊社英名「LangEdge,Inc.」を書いて申請したら「ここはローマ字で表音を書く欄だから不可」と言われてショボーンとしたものでした。しかし今年になって法務省の担当者とお話をする機会がありこの件を聞いたところ「いやそこには英語社名を書いて構いません。むしろ書くべきです。」と言われました。

そこで今年は申請時に英語社名で申請をしてみました。しかし「商号又は名称の表音・略称等」に英語法人名を使うには以下の提出物が必要と言われました。

　１） 英語法人名が書かれている定款の全ページコピー
　２） コピーの先頭ページに代表が一筆（※）と署名押印する

　※ 「この定款は○○社のものと認める」みたいな一筆とのこと

まあ確かに商業登記には英語法人名と言う登録項目は無いので別の手段で確認が必要と言うことは分かります。と言うことで今年は英語法人名の登録に失敗しましたが、もしこれから申請される方がいらっしゃいましたら是非トライして結果を教えて頂けるとありがたいです。弊社は来年またチャレンジしたいと思います。

そもそも国際化の時代に商業登記内容に英語名が無いことが問題ですよね。この辺り改善して行かないと世界に通用しないのではないでしょうか。って久しぶりにまともな内容のブログでしたw もっと更新しなきゃなぁ…

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

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

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

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

ここではSHAttered問題の解説では無く、特にドキュメントやデータに対する電子署名についての状況と考えられる対応を簡単にまとめます。
[続きを読む]

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

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



この言葉自体を今後使うかどうかは別にしてIoTも含めてトラストを守るセキュリティ分野に活動の幅は広げて行こうと考えています。さてどうなりますかw

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

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

開発者や仕様策定者向けですので一般向けの内容ではありません。PDF電子署名はPDF内部知識と電子署名の知識と両方が必要なのですがPDFの知識はなかなかPKI技術者には敷居が高いようで皆さんの要望を受けて行った勉強会の資料です。とは言え全部を説明するのは難しいので「なんとなく分かった気になる」としています。PDF電子署名にご興味があればご笑覧ください。

ああ。3月も終わります。正月以降にBlog更新していません…orz いやネタは溜まっているのですが。と言う事でまず簡単なネタと言う事で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

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

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

３）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の活動報告もまとめたいと考えています。時間が無い～(^^;

久しぶりの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を使わざるを得ません。１つ可能性があるのは古いCAPIのAPIを使えばこの問題が生じないのでは無いかと言う事なのですが…まだチェックしていません。追加で何か分かったら書き足します。

何はともあれ .NET で RSA署名 を ドメインコントローラ利用環境 で使った場合には通信のオーバーヘッドによる速度低下があると言う情報を残します。と言ってもこの情報を必要としている人はほとんどいないかも(^^;;;

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

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

JNSAの標準化部会に新しく作られる電子署名WGの活動が開始されました。まず4月24日に説明会があり、5月23日に第１回目の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ファイルへのリンクですのでご注意ください。

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

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





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

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

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

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

と言うことでPKI業界的には10月10日は商業登記証明書新ルート発行の日と言うことで(^^;

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

指摘：
「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 これから本文。本文はもっと長いです(^^; [続きを読む]

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年ですね(^^;