私の活動のうち公開されている情報をまとめた [公開情報]のページ を更新して最新の活動内容を反映しました。我ながら色々資料を作ってますねw まあ15年以上分ですから。最近はこのブログでは無く Qiita に技術記事は書くようになりました。日々のたわいない記事はFacebookに書くようになってしまいましたので非公開になってしまいました。Facebookはオンラインも含めお会いしたことがある方のみフレンド登録させて頂いています。フレンドになりたい方は是非お仕事を(^^; あと Twitter でも情報公開しています。これからも情報公開して行きますのでよろしくお願いします。

「PDF長期署名ライブラリLE:PAdES:Lib」と「PDF基本署名ライブラリLE:PAdES-Basic:Lib」がバージョンアップして、V1.07.R2 となりました。追加された主な新機能や修正等は以下となります。

１）HSM（※1）対応の機能やドキュメントの整備
　→ 仮署名2（LePAdeS.makeEnhanced2機能）利用の整備
　→ LpaCmdにて外部で署名値計算を行う仮署名2の機能を追加
　→ Linux版にて仮署名2用にX.509証明書の指定機能を追加
　→ 仮署名2のLpaCmd利用サンプルを追加
　→ CAdESハッシュ値計算時にハッシュアルゴリズム指定を追加
　→ マニュアル「４．８．HSMによる署名の利用（仮署名）」の追加
　※1 HSM：ハードウェア・セキュリティ・モジュール
２）Windows版にICカード設定を指定するLpkCert::setCard2を追加
　→ プロバイダ名/種別/フラグや鍵種別等のパラメータが指定可能
　→ LpaCmdにてJPKI/GPKI等の国内ICカードに対応とパラメータ公開
　→ マニュアル「４．６．CAPI対応IC カードによる署名の利用」参照
３）以下の新機能に対応
　→ Linux版として従来のCentOS以外にAmazon Linuxビルド版の提供
　→ 互換性向上の為に一部のCAdESデータ仕様への対応
　→ Windows版でWindows証明書ストアのCNG形式での登録秘密鍵に対応
　→ マニュアル４章を「４．ＰＫＩ要素と署名方法」として全面更新
　→ PDFのハイブリッドXREF構造への対応

■ 修正項目：
　→ メタデータが暗号化されたPDFの読み込み時に失敗する問題の修正
　→ 署名データ用の確保領域を15KBから17KBに増やした
　→ MDP署名にて/Pキーが無い場合に読み込みに失敗する問題の修正
　→ 署名フィールド名に日本語が使われている場合の問題を修正

その他詳細は製品ダウンロードページ（LE:PAdES:Lib / LE:PAdES-Basic:Lib）でご確認ください。製品ダウンロードページでは認証が必要です。その他「PDF長期署名ライブラリLE:PAdES:Lib」について詳しくはアンテナハウスのページをご覧ください。評価版もご用意しておりますのでご興味があればアンテナハウスよりお申込みください。

Qiitaに「Re:ゼロから始める長期署名」を公開しました。ご笑覧ください。長期署名についての書籍も古いものしか無かったり、いまさら長期署名の基礎を解説する記事も無かったり、と言うことであらためて基本から書いてみました。新しい長期署名フォーマットとしてJSONベースのJAdES仕様が公開されましたので簡単にそれにも触れています。
https://qiita.com/lemiyachi/items/87d698e51e4a53c721d6

「クライアント署名 LE:Client:Sign」がバージョンアップして、Ver2.1 となりました。Ver2.1 ではサーバ連携せずにローカル環境側で利用可能な以下機能が追加となりました。

　１）クライアント署名のみでXAdES-BESの生成が可能。
　２）クライアント署名のみで証明書情報(JPKI/商業登記等)の取得/判定が可能。

その他詳細は製品ダウンロードページ（LE:Client:Sign）でご確認ください。製品ダウンロードページでは認証が必要です。「クライアント署名 LE:Client:Sign」について詳しくは弊社の製品ページをご覧ください。デモ環境も用意していますのでお問合せ頂ければURLをお知らせします。

「PDF長期署名ライブラリLE:PAdES:Lib」と「PDF基本署名ライブラリLE:PAdES-Basic:Lib」がバージョンアップして、V1.07.R1 となりました。追加された主な新機能や修正等は以下となります。

新機能：
１）クライアント署名V2.1をサポート
　→ Edge/Chromeでのクライアント署名が可能
　→ XAdES-BESローカル署名に対応（サーバ連携不要）
　→ 証明書情報をローカルで取得可能（JPKI/商業登記証明書他）
　※ ASP/OEMは別途クライアント署名ライセンスが必要
２）以下の新機能に対応
　→ Linux版でもXMP操作が可能となった
　→ Windows版でVisualStduio 2017/2019に対応した
　→ AES-256bitsの暗号化に対応した
　→ Java/.NETで最後のエラー lastError() のAPIを追加した
　→ 証明書クラスでJPKI/商業登記証明書の情報取得APIを追加した
　→ 簡易添付ファイル対応のAPIを追加した（他社互換性は非保証）
　→ Windows版で libxml2.dll と zlib1.dll が不要になった

修正項目：
　→ HTTP/LDAP通信に失敗した場合には1度だけ0.5秒待ってリトライする
　→ 署名データ用の確保領域を15KBに増やした
　→ リンク証明書を使った場合の認証パス構築不具合の修正
　→ 署名時のメモリ利用量を削減した
　→ Windows版でBasic認証付きPROXYの認証情報の設定方法の変更
　→ Linux版でSquidにおいてhttps通信時に失敗をしていた問題の修正
　→ その他互換性向上（読めないPDFへの対応等）

その他詳細は製品ダウンロードページ（LE:PAdES:Lib / LE:PAdES-Basic:Lib）でご確認ください。製品ダウンロードページでは認証が必要です。その他「PDF長期署名ライブラリLE:PAdES:Lib」について詳しくはアンテナハウスのページをご覧ください。評価版もご用意しておりますのでご興味があればアンテナハウスよりお申込みください。

「クライアント署名 LE:Client:Sign」がバージョンアップして、Ver2 となりました。Ver1 ではIE11上で動作するActiveXコンポーネントのみでしたが、Ver2となり新EdgeとChromeに対応した署名コマンドをサポートしました。ActiveXコンポーネントと署名コマンドでは証明書取得と署名値計算のAPIに大きく変更はありませんが、署名コマンドは別プロセスで起動される為に通信のWebSocket接続APIを最初に実行する必要があります。

「クライアント署名 LE:Client:Sign」について詳しくは弊社の製品ページをご覧ください。デモ環境も用意していますのでお問合せ頂ければURLをお知らせします。

新型コロナの影響で業務の電子化の推進が加速しています。電子署名もあちこちから注目を集めるようになって来て色々な電子署名サービスも出てきました。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	署名サービスの運用や監査のレベル

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

2020年6月1日付けでラング・エッジはOpenIDファウンデーション・ジャパンに入会しました。

OpenIDファウンデーション・ジャパン
https://www.openid.or.jp/

ラング・エッジはどちらかと言えばPKIを利用した電子署名系に強い会社ですが、このクラウド社会（それに新型コロナ後社会）では例えばリモート署名と呼ばれる仕組みが求められています。リモート署名ではOpenID/OAuth系の電子認証技術がとても重要な要素となります。なおラング・エッジ加入済みのJT2A（日本トラストテクノロジー協議会）では4月30日にリモート署名のガイドラインを出しました。

リモート署名ガイドライン
https://www.jnsa.org/result/jt2a/2020/index.html

このリモート署名ガイドラインも電子認証の知識がないときちんと理解できないかもしれません。今後は電子署名と電子認証を組み合わせたサービスの必要性が高まると予想しており、ラング・エッジではその分野について取り組みを深める予定です。今回のOpenIDファウンデーション・ジャパンへの入会はその最初の一歩と考えています。この分野に関する案件や疑問等ありましたらお気軽にご連絡ください。

流石にもうオンプレでサーバを運用する時代でもなかろうと言うことでサクラVPSにサイトを移動しました。ついでにブログのNucleusも最新にしとこうと…思ったら少し苦労したので書いておきます。

まずこれまで使っていたのは Nucleus CMS v3.23 でした。古いですね…ごめんなさい(^^; それを最新の Nucleus CMS v3.71 にしました。しかしその間には深くて暗い川がありましたw 問題は文字コードの扱いの変更です。NucleusにはDB保存/復元の機能があるのですがなかなかうまく使えないことがあってついmysqlのダンプを使ってしまいます。

ダンプを取る：
$ mysqldump [dbname] -p[passwd] -u root > dump.sql

ダンプから戻す：
$ mysql -p -u root [dbname] < dump.sql

これでv3.23のままなら問題なし！しかしv3.71にすると表示が文字化けします。また文字コードが違うとのメッセージも表示されます。

解決方法をサクッと書いてしまうと、ダンプから戻す時に使うファイル（上例ではdump.sql）をNucleusのDB保存で保存したファイルを使いましょう。上書きされるので文字化けした状態で実行して構いません。これで直ったはずです。

原因は直接myjsqldumpするとDBの文字指定がlatin1になってしまう為です。DB保存だとUTF8になります。Nucleusの最新では文字コードの一致をちゃんとチェックしているのでエラーになると言うことです。

あとこれは私だけかもしれませんが admin の css ファイル名が、admin_.css となっていたので libs/ADMIN.php を修正して admin.css を参照するように変更しました。

この状態で upgrades でDBを更新すると全て正常に更新されてバージョンアップ完了です。久しぶりに Nucleus をいじりましたw もし困っている方がいたらご参考に。

オープンソース署名＆認証ラボ、略称OsSAL（Open-src Sign and Auth Labo）と言う研究ラボをラング・エッジが主スポンサーとなって開始しました。詳しくはOsSALのサイトをご覧ください。

https://www.ossal.org/

本研究ラボの目的は認証を絡めた署名等の仕組みの研究や勉強と、関連したオープンソースのプロジェクト開発となります。署名認証系プログラマのお役に立てるように頑張ります。年に1～2回程度の勉強会（サルオフ）も計画しています。

プログラマが楽しめる活動にしたいと考えています。参加は無償かつ自由ですのでご興味があれば是非ご参加ください！

ラング・エッジは２０１８年１２月２９日（土）より２０１９年１月６日（日）まで年末年始の休暇とさせていただきます。新年は１月７日（月）より通常業務となります。休業期間中におきましてもメールをチェックしておりますので、もし何かありましたらメールにてご連絡ください。

以上よろしくお願い致します

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

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

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

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

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

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

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

「PDF長期署名ライブラリLE:PAdES:Lib」と「PDF基本署名ライブラリLE:PAdES-Basic:Lib」がバージョンアップして、V1.06.R1 となりました。追加された新機能や修正等は以下となります。

新機能：

１）クライアント署名V2をサポート
　→ CAdES署名が可能（V1ではPKCS7.SHA）
　→ 1つのプラグインでPAdES/XAdESに対応可能
　→ クライアント署名V2用のAPIの追加
　※ ASP/OEMは別途クライアント署名ライセンスが必要
　※ 引き続き従来のクライアント署名V1も利用可能
　マニュアル「7. クライアント署名(Ver2)」参照

２）署名外観に透過PNG画像が使えるようになった
　→ 透過部をマスクして背景が抜ける印影が可能
　→ PNGからビットマップ化するので画像劣化しない
　マニュアル「3.4. 署名外観」参照

３）PDF解析機能の新規追加
　→ 検証では無くPDF内部構造をXML形式で出力する機能
　→ PDF解析結果XMLレポート用LpaParseXmlクラスの追加
　→ PDFに関する基本/署名/画像の情報の取得
　1 基本:タイトルや作成者等のPDFプロパティ情報
　2 署名:署名/タイムスタンプに関連するPKI/PAdES情報
　3 画像:各ページに含まれる画像情報(オプション)
　※ 画像情報はDPI等も取得可能（埋め込み情報/計算）
　マニュアル「9. PDF解析結果XML」参照

４）CAdES署名にてAdobe仕様の失効情報の埋め込み対応
　→ 署名前取得CRL/OCSPの署名データへの埋め込み
　→ 検証時にもAdobe仕様の埋め込み失効情報に対応
　※ 注意事項が多い為に本機能の利用時には要相談
　マニュアル「3.7. Adobe 仕様の失効情報」参照

５）CAdES署名時のHSM対応APIの追加
　→ CAdES署名対象のハッシュ値の取得等のAPI追加
　※ リモート署名への対応が可能
　マニュアル「4.10. HSM」参照

６）検証時のCRL優先/OCSP優先の指定を可能
　→ 従来はOCSP優先のみだったが選択が可能になった
　※ デフォルトがOCSP優先からCRL優先に変更された
　マニュアル「4.9. 失効情報取得の高度な指定 1)」参照

７）LePKIインスタンスにCRL/OCSPキャッシュ化が可能
　→ 同じインスタンスで検証することで高速化が可能
　→ 取得CRL/OCSPをメモリ上独自証明書ストアに格納
　マニュアル「4.9. 失効情報取得の高度な指定 2)」参照

８）LE独自検証プロキシサーバのサポート
　→ 失効検証時の外部接続URLを1つにすることが可能
　→ 独自検証プロキシサーバはLE独自仕様
　→ Tomcat用のサーバサンプルの提供
　マニュアル：「4.9. 失効情報取得の高度な指定 3)」参照

９）OCSPURL未設定証明書でOCSPURLを外部指定可能
　→ 証明書未記載でもOCSPをサポート時に利用可能

修正項目：

Ａ）検証時の優先をOCSP優先からCRL優先に変更
　→ オプション指定で従来通りOCSP優先も可能
　→ 有効期間が短いOCSPが増えてきた為に変更

Ｂ）マイナンバーカードへの対応
　→ 住基カードは未サポートに変更

Ｃ）可視署名時に署名外観（画像/TEXT）無しを許した
　→ 別途画像を埋め込んだ署名に対応

Ｄ）JAVA APIの障害修正
　→ Windows版LpkCadesのネイティブ部の障害修正
　→ LpkCert.getCrlDps()実装不足の追加
　→ Linuxで大量署名フィールドがある時の障害修正

Ｅ）.NET APIの障害修正
　→ PdaVerifyXml::getReport()引数englishの障害
　→ スレッド時のタイムスタンプ処理問題を修正

Ｆ）他社PDFファイルとの互換性向上
　→ 読み込み時にエラーになっていたPDFへの対応

Ｇ）その他細かな障害対応
　→ XMPのUTFの問題やメタデータ暗号化の問題の修正
　→ 特定のケース/利用方法で発生する障害等への対応

Ｈ）試験（サンプル実行）用の独自証明書類の更新
　→ 期限切れにともなう更新

Ｉ）アマノタイムスタンプサービス3161の更新
　→ ライセンスファイル形式更新への対応
　※ LE:PADES:Lib Ver1.05.R1e で対応済みの項目

「PDF長期署名ライブラリLE:PAdES:Lib」について詳しくはアンテナハウスのページをご覧ください。評価版もご用意しておりますのでご興味があればアンテナハウスよりお申込みください。アンテナハウスのサイトにおいても間もなく本バージョンのリリース案内が出る予定です。また既存のお客様にも間もなくダウンロードのご連絡を差し上げますが、お急ぎの場合には保守担当窓口までご連絡ください。

ラング・エッジの電子署名製品試験用の試験認証局リポジトリを更新して公開しました。

　試験認証局リポジトリ

製品には試験用に従来から試験用のタイムスタンプサービスや署名用証明書を提供していました。月日が経つのは早いもので、最初に用意していたルート証明書の有効期限が今月20日に終了します。そこで新たにルート証明書を更新しました。これに伴いラング・エッジがフリーで提供しているタイムスタンプサービスのTSA証明書とルート証明書も更新されましたのでご注意ください。

また製品のサンプル実行を行う場合にも証明書の入れ替えが必要となります。ラング・エッジの電子署名製品とその評価版をご利用の場合には以下のファイルをダウンロードして入れ替えてお使いください。

　LE製品サンプル更新ファイル

詳しくは試験認証局リポジトリをご覧ください。お手数をおかけしますがよろしくお願い致します。

明けましておめでとうございます。2018年ですね。皆様のおかげで昨年も無事に乗り越えることができました。まずはこの場でお礼を申し上げます。ありがとうございました！

さて今年の年賀画像は量子コンピュータからRSA暗号を解く為のショアのアルゴリズムを量子ゲートで表した量子回路図です。量子ゲート型の量子コンピュータではこれがプログラミングとなります。これがあればすぐにRSA暗号が解けてしまい電子署名が通用しなくなる～！と言うことはありませんのでご安心ください。アルゴリズム…つまりソフトウェア的には解けるのですが、何せハードとして数万単位の量子ゲートが無いと実用にはなりません。あと10年くらいは楽勝で大丈夫でしょう。とは言え将来を見据えて耐量子コンピュータの暗号も米国NISTでは準備が始まっています。以下にエントリーしている中から次世代の公開鍵暗号も決まるのだろうと言われています。

NIST: Post-Quantum Cryptography, Round 1 Submissions

と言うような新しいこともやりつつ、今年も本業の電子署名系のお仕事やクラブ活動を頑張ります！今年はJNSA電子署名WGだけでは無く新団体JT2A（日本トラストテクノロジー協議会）の活動も重要になりそうです。きっと今年も貧乏暇無しだと思いますが、あきれずおつきあいください。それでは今年もよろしくお願い致します！