そこで今年は申請時に英語社名で申請をしてみました。「商号又は名称の表音・略称等」に英語法人名を使うには以下の提出物が必要と言われました。「この定款は○○社のものと認める」みたいな一筆とのことまあ確かに商業登記には英語法人名と言う登録項目は無いので別の手段で確認が必要と言うことは分かります。言うことで今年は英語法人名の登録に失敗しましたが、もしこれから申請される方がいらっしゃいましたら是非トライして結果を教えて頂けるとありがたいです。弊社は来年またチャレンジしたいと思います。そもそも国際化の時代に商業登記内容に英語名が無いことが問題ですよね。この辺り改善して行かないと世界に通用しないのではないでしょうか。miyachi]SHA-1ハッシュアルゴリズムの危殆化はずいぶん前から叫ばれてきましたが、とうとうSHA-1衝突問題(SHAtteredと呼ばれる)が、2月23日にGoogleとオランダのCWI研究から公開されました。ここではハッシュ値が同じで異なるPDFファイルも公開されており、90日後に手法を公開すると予告されました。比較的詳しいニュースとしてはGigaZineで、参考になるスライドがサイボウズの社内勉強会のスライドとして公開されています。詳しくはこちらをご覧ください。GigaZine:Googleがハッシュ関数「SHA-1」を破ることに成功、90日後に手法を公開予定サイボウズの暗号とセキュリティ社内勉強会用スライド:GoogleのSHA-1のはなしここではSHAttered問題の解説では無く、特にドキュメントやデータに対する電子署名についての状況と考えられる対応を簡単にまとめます。miyachi]電子署名関連製品を開発して、JNSAの電子署名WGで活動しています。ところでこの「電子署名」と言う言葉が「古い」「目新しさが無い」等と言われて久しく、「電子署名終わっているよね?」みたいな言い方をされる事もあります...困ったものです(^^;まあ確かに「電子署名」と言えば電子文書やデータに対するイメージもあって応用もしにくいですね。言うことで「電子署名」も含んだ新しい言葉を考えてみました。それは「トラスト・セキュリティ」です。Google先生で検索してみると意外に先にこの言葉を使っている人はいないみたい??ただ警備系の会社名では結構使われていそう...ま、まあとりあえず公知にしとくかってことでSlideShareに上げてみました。この言葉自体を今後使うかどうかは別にしてIoTも含めてトラストを守るセキュリティ分野に活動の幅は広げて行こうと考えています。miyachi]新年度になりましたので昨年度の資料を整理していてそう言えばこの資料は公開していなかったなぁ...と言う事で公開します。JNSA電子署名WGのスキルアップTF勉強会ネタとして10月に行った「なんとなく分かった気になるPDF電子署名仕様入門2」です。以下よりダウンロードください。なんとなく分かった気になるPDF電子署名仕様入門2http://www.langedge.jp/download/jnsa/20131030-SUTF-4-pdfsign.pdf開発者や仕様策定者向けですので一般向けの内容ではありません。PDF電子署名はPDF内部知識と電子署名の知識と両方が必要なのですがPDFの知識はなかなかPKI技術者には敷居が高いようで皆さんの要望を受けて行った勉強会の資料です。言え全部を説明するのは難しいので「なんとなく分かった気になる」としています。PDF電子署名にご興味があればご笑覧ください。miyachi]ああ。いやネタは溜まっているのですが。言う事でまず簡単なネタと言う事で1月以降に発表した内容を整理しておきます。2014JNSAの電子署名WGで50分時間を貰えたのでミニパネルのパネラーの一人として発表しました。言え時間が短いので実質10分程度の発表です。資料は以下になります。420KB程度ありますのでご注意を。内容としては1年間の活動成果を簡単にまとめて今後活動の説明となっています。海外動向等も電子署名WGの皆さんが発表されています。今後に向けて」~スキルアップTFの活動から~http://www.jnsa.org/seminar/nsf/2014/data/NSF2014_A2-4_miyachi.pdf2)2014年2月4日:ITフォーラム2014こちらはAITCのクラウド・テクノロジー活用部会からの発表です。気象庁XML(気象庁防災情報XMLフォーマット)と言うオープンデータをネタにメンバーで発表しており、私はセキュリティの可能性についてまとめて発表しました。こちらも短く15分程度の発表でした。資料は公開されていないのでこっそり以下に公開しましたのでご笑覧ください。1.2MBくらいあります。2014JNSA電子署名WGとしての発表です。恐れ多い事ですが時間も2人(亀田さんと)で1時間以上貰ったのでクラウド署名等について濃く話が出来たかなと思っています。1.4MBくらいあります。~クラウド/モバイル署名と非PKI署名~http://www.jnsa.org/seminar/pki-day/2014/data/PM02-1_miyachi.pdf以上3イベントに参加発表しました。話をしているうちにだんだん自分の考えも整理できてくるのでやはりこういうチャンスを頂けるのはありがたいですね。次は電子署名WGの活動報告もまとめたいと考えています。miyachi]久しぶりのPKIプログラミングネタです。Windowsでは電子署名をするのにCAPIや.NET等の幾つかのAPIが用意されています。メソッド、つまりRSA署名とRSA検証のAPIの実行速度が遅くなると言う問題が見つかりました。methods最初はアクティブディレクトリ認証(以後AD認証)が必要なサーバでのみ速度が遅く、LDAP通信が頻発していると言う事でした。どこでLDAP通信されているのか分からずテストプログラムを作成して試して頂きました。Windows証明書ストアへのアクセスにAD認証が必要なのではと予想したのですがハズレでした。結局RSA検証している箇所が遅くRSA検証を.NETからOpenSSLに変更したところLDAP通信が無くなったのでした。そこからS社のMさんが見つけたのが上記リンクのページです(Mさんありがとうございました)。確かにこれに該当していたようです。RSAクラスにはハッシュアルゴリズムが指定可能であり、昨今ではSHA-2も指定する必要があります。デフォルトのSHA-1以外のハッシュアルゴリズムを利用した時にドメインコントローラに問合せに行ってしまうとのこと。言うことでこういう事もあろうかと用意していたOpenSSLを使って全く同じ処理をするモジュールに切り替えて問題解決したのでした。RSA検証はこれで良いのですがRSA署名にWindows証明書ストアの秘密鍵を使う場合にはOpenSSLでは対応できないのでWindowsのAPIを使わざるを得ません。1つ可能性があるのは古いCAPIのAPIを使えばこの問題が生じないのでは無いかと言う事なのですが...まだチェックしていません。追加で何か分かったら書き足します。使った場合には通信のオーバーヘッドによる速度低下があると言う情報を残します。miyachi]最近はFaceBookばかり書いていてブログがおろそかになっていてすみません。最近の出来事や書いた資料等を簡単にまとめます。JNSA電子署名ワーキンググループ発足JNSAの標準化部会に新しく作られる電子署名WGの活動が開始されました。4月24日に説明会があり、5月23日に第1回目のWGが開かれました。うちのような電子署名系ベンダーはもちろん認証局やタイムスタンプ局の皆さんも参加されてバランスが良いワーキングになったように感じました。残るはユーザ系の企業が入ってくれればと言うところですが、ユーザ系企業の人を呼んできてお話を聞くことはできそうです。ECOM時代には及びませんが良い感じのスタートが切れたのではないでしょうか。ちなみに電子署名WGの下で活動するTF(タスクフォース)は今のところ以下の3つです。署名検証-TFTBFで昨年度行ってきた活動をJNSAで継続。検証手順の標準化は実はありません。検証が必要な項目や内容を整理して標準化を目指します。PAdES-TFPDFの長期署名であるPAdESの標準化活動。PAdES仕様について問題点の確認やプロファイル作成を目指します。スキルアップ-TF(仮称)唯一標準化では無く参加者のスキルアップや教育の場を提供します。メンバーの興味がある内容について講師を設定して説明して貰います。オープンソースの長期署名ライブラリFreeXAdES開発と勉強会を実施予定。私は全部参加することになりますが特にスキルアップTFはメイン担当になりそうです。情報化社会のインフラとなったPDFの解説本が0.30版になりました。アンテナハウスのCAS-UBを使った電子書籍として公開されています。0.30版では私の方でPAdESの説明を書きました。フリーダウンロード可能ですのでPDFやPAdESのご興味があれば是非ご覧ください。Acrobat-XIでPAdESファイルを作成するJNSAの電子署名WG説明会で簡単に説明した資料を公開しています。最新のAcrobat-XIを使ってPAdESのLTV対応のファイルを作成する方法を説明しています。こちらからダウンロード。PDFファイルへのリンクですのでご注意ください。電子署名を使う場合にまず設定して欲しいのが「Windows証明書ストア利用設定」です。以前本ブログでも書いたことがあるのですが、Acrobat-XIでは設定方法も変更されているので一度きちんとまとめておきます。同じ内容をPDFファイルにしましたので、よろしければダウンロードして再配布等自由にお使いください。miyachi]毎年10月10日になると商業登記証明書は新しいルート証明書が有効になります。これだけなら大したことは無いように思うかもしれませんがPDF電子署名ではちょっと困った問題を生じます。昨日まで有効だった商業登記証明書で署名したPDFをAcrobatかReaderで開くと以下のような画面となり検証結果が「不明」となります。これは失効確認に利用するOCSPの署名が新しいルート証明書に切り替わった為に、署名証明書のルート証明書と一致しない為です。これを防ぐ為には別ルート証明書でも信頼するルート証明書であれば良いとか、より正確にはリンク証明書を使うとかすれば大丈夫です。AdobeのAcrobat/Readerがこれに対応することは無いのではないかと思います。Acorbat等では「不明」と表示されますがGPKIの証明書検証サーバ等では正常に検証されますので電子申請等に使う分には全く問題ありません。代表印の代わりに民間同士の電子契約等で使う場合にはちょっと嫌ですね。これを運用で防ぐには自社の商業登記証明書も同じく10月10日で新しいものに変えるくらいしか今のところ対応方法がありません。Adobeさん対応してくれませんかねぇ...なお弊社のLE:XAdES:Libや今開発中のLE:PAdES:Libではリンク証明書等にも対応していますので正常に検証が可能です。miyachi]こちらもサイトリニューアルに伴ったご指摘です。指摘:「DRM(鍵管理)ってとこはDRM=鍵管理と捉えられるとちょっとどうかと。内容についてのご指摘ですね。そこは直してみました。Management)の定義は「デジタルコンテンツの著作権を保護して、その利用や複製を制御制限する技術」だと考えています。その意味で鍵管理とDRMはイコールでは無いだろうと言うのはご指摘の通りだと私も思います。この真意としては逆にDRMにおいて鍵管理以外の部分(例えばユーザ管理やコンテンツ管理や権限管理)は、既存の認証技術やデータベースやWebサービスで実現が可能であり、クライアント端末に保管する鍵がきちんと管理する部分が最も重要になると私的には考えているからです。ちなみにDRMと同じような仕組みであってもオンラインで利用するコンテンツに対しては暗号化では無く「アクセス制御」で済むケースが多いです。動画配信をするとして、クライアントPCに保存出来ないストリーム配信ならアクセス制御だけで良いですが、動画ファイルをダウンロードさせてオフラインでも利用する為にはDRMの仕組みが必要になります。その意味ではDRMはクライアントにおいてオフライン時に「利用を制限」する仕組みだと考えています。DRMでは一般に暗号化されたコンテンツを復号して利用します。復号する為の鍵をどのように管理するかがDRMシステムのポイントとなります。従来のDRMの仕組みでは秘匿された鍵を利用していました。この秘匿している仕組みが分かってしまうと復号する為の鍵が取得出来てしまい不正利用が可能となってしまいます。復号は必須である為に100%破れない仕組みは不可能となります。この為にDRMでは破られた場合の移行手段も考慮に入れるか、破られるリスクも含めてビジネスモデルを構築する必要があります。このようにDRMの仕組みの中で一番クリティカルな箇所はクライアントでの鍵管理だと考えている為に一見すると「DRM=鍵管理」的な説明になっていると思います。言い方を変えるとクライアントでの鍵管理さえきちんとできればDRMの他の部分は比較的容易に実現が可能と考えていると言うことです。できるだけ既存の技術で可能な範囲はそのまま利用すべきだと考えていますので、鍵管理の部分だけ提供すれば良いと考えています。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では移行指針を示して具体的に運用に必要な内容がまとめられています。以下を参照しています。LGPKI:暗号アルゴリズム移行に伴うドキュメント追加についてスケジュール的に現在は「新旧両暗号に対応・現行の暗号を利用(フェーズ1)」にあたります。平成26年度より「新旧両暗号を利用(フェーズ2)」となり、最終的には「新たな暗号のみ利用(フェーズ3)」となります。平成25年度末までには新暗号(RSA2048/SHA2)への対応を完了させる必要があります。技術的に見て新暗号(RSA2048/SHA2)対応するのに必要なポイントとしては、証明書検証サーバやリポジトリ(ディレクトリサーバ)が新旧あったり、ICカードを利用した署名プラグインの更新があったり、もちろん中の暗号ライブラリも含めて新暗号(RSA2048/SHA2)対応する必用があると言うことになると考えています。単純に証明書が新暗号(RSA2048/SHA2)対応すれば良いと言うのとは少し違った面で作業が必要になると考えています。私の真意としては少し広く捉えると言うか運営側から見て必要となる全てのソフトウェアのアップデートへの対応が弊社にて可能だと言う事を言いたかったと言うことになります。弊社はソフトウェアベンダーなので運営側からの見方になってしまっていると思います。いえそれ以前に私がきちんとまだPKIを理解していないと言う面ももちろんあると思います。不足しているのは勉強して行き訂正して行ければと考えていますのでこれからもご指摘よろしくお願い致します。以下は少し補足と言うか余談的な話になります。miyachi]「その壱」では主にOpenLDAPのバイナリの入手等について書きましたが、今回はプログラミング編です。PKIのプログラミングではLDAPのディレクトリサーバから証明書やCRLを取得する必要に迫られます。Windows環境ならCryptoAPIでも可能ですが、マルチプラットホームを考えるとOpenLDAPを使った方が良いですよね。ちなみにWinLDAPとOpenLDAPはAPI的にはほぼ同じです。微妙な違いや動作に違いがありますがそれは今回説明する予定です。LDAPクライアントとして情報を取得する手順は大きく言って以下の4つです。紹介(Referral)とは、相互運用されているPKIドメインで自ドメイン以外の検索要求があった場合に、情報を持っているであろうディレクトリサーバを紹介されるケースです。JPKIの証明書をLGPKIのディレクトリサーバに要求すると以下のようになります。ONにすると自動的に辿ってくれるはずで、WinLDAPは何もしなくても1)の結果6)が返ってきます。OpenLDAPでは何か私が間違っているのだと思いますが自動で辿ってくれなかったので、自分で辿っています。それではソースコードです。エラー処理は入っていませんのでご注意ください。miyachi]PKIの世界ではCRLや証明書はLDAPのディレクトリサーバから取得することが多いです。日本のGPKI/LGPKI/JPKI等の相互認証しているPKIドメインだとディレクトリサーバも公開されていますし、使わなければ損な状況でもあります。余談ですがLDAPのポート番号はldap:389/ldaps:636となっていて、企業内からだとファイアーウォールで許可されていないケースも多いです。この為にPKI現場のSEの皆さんにはLDAPは結構不評だったりするのですが...(^^;閑話休題。Windows環境でクライアントとしてLDAPを使うAPIとしてWinLDAPが提供されています。これまで私もWinLDAPを使ってきたのですが、最近どうも調子が悪い...と言うよりも実行に時間がかかるようになっていることを発見。7環境だと秒単位でかかります。LDAPはCAPI(CryptoAPI)のCryptRetrieveObjectByUrl()でも取得可能です。ここにCAPIを使ったCRLの取得について説明があるので参考になります。7環境ではやはり秒単位の時間がかかります。内部的には同じAPIを呼んでいる気がします。遅くなった理由が全く解せない。言えある案件で時間も無かったので解析するよりもOpenLDAPを使ってみようと思い立ちました。FrameworkによるRSA-SHA2署名(完結編)」を投稿していましたが、ICカード対応でCryptoAPIでRSA-SHA2署名を実装する必要があり調査してみました。Framework編と同じ理屈で動作したので、CryptoAPI(CAPI)対応編としてまとめます。Framework編をお読み頂きたいのですが、暗号プロバイダとして標準のPROV_RSA_FULL(1)からSHA-2に対応したPROV_RSA_AES(24)に切り替える必要があります。PROV_RSA_AESで証明書に関連付いた秘密鍵を使う方法をソースコードとして以下にまとめます。適当な方法で用意して下さい。以下ではエラー判定は行なっていませんし開放もちゃんとやっていませんのでエッセンスのみと考えてご覧下さい。&dwSize);色々余計なことをしているかもしれませんこれで動作しました。ソースが長くてすみません。ポイントとしては普通にPROV_RSA_FULLの秘密鍵を取得して、そこから秘密鍵の鍵プロバイダ情報をCertGetCertificateContextProperty()で取得し、pwszContainerNameを使ってPROV_RSA_AESの暗号プロバイダハンドルを取得しています。XPではSP3以降が必須となりますのでご注意下さい。検索してもCAPIでRSA-SHA2署名の情報があまり無かったので参考になれば幸いです。ソフト」が無償公開されているのは以前もブログで紹介していましたが、今回弊社の商業登記証明書を商業登記電子認証ソフトを使って取得してみました。商業登記電子認証ソフトを確認したところ昨年末にVer1.1がリリースされていました。画面の修正等のようです。起動してみて派手なメニュー画面から「手順1:鍵ペアファイル及び証明書発行申請ファイルの作成」を選びます。右の画面が開かれますので必要項目を入力します。必要最低限になっているようでその点は使いやすそうです。ちなみに「商号又は名称の表音・略称等」には英語名は駄目だと以前言われました。表音なので会社名をローマ字で書けと...オプションなので私は省略です。ファイルの格納先はフォルダダイアログで指定しますが開く度に初期位置に戻るのは使い難いです。入力して下にある「鍵ペアファイル及び証明書発行申請ファイル作成実行」をクリックすればOKです。ファイルを確認します。言っても中の確認は出来ないので存在確認だけですが。ちなみに1KB未満の小さなファイルです。これをCD-Rルートに焼いて法務局に持って行きます。"日時番号+申請書・委任状.pdf"を確認します。申請書のPDFファイルが出来るのは便利ですね。生年月日と請求する証明書の期間を入力すれば印紙を貼ってそのまま法務局の窓口に持って行けます。言うことでCD-Rを作成して申請書と代表印の印鑑カードの3点を持って法務局窓口へ。今回は24ヶ月の証明書にしたので印紙は15,100円でした。CD-Rは返してくれません。ソフト」を起動します。ボタンをクリックすれば無事にPKCS#12形式の証明書+秘密鍵が入手出来ます。以前は有料のソフトが無いと駄目だったですしフロッピーディスクだけでしたが、無償ソフトとCD-RでOKになったので取得しやすくなりましたね。大企業では取得するのも大変だと思いますが中小零細企業なら取得も簡単だと思います。弊社の「図面XML署名ツール」による図面申請時等にも使えますし法人(正確には代表者)の公的な証明書として良いと思います。商業登記証明書ももっと使える場が増えると良いですね。miyachiありがとうございます。kjurお疲れ様です。LangEdge,Inc.。