「クライアント署名 LE:Client:Sign」がバージョンアップして、Ver2.1.R2 となりました。追加された主な新機能と修正項目は以下となります。

■ 新機能：
　→ マニュアルの「4.1. 独自通信XMLプロトコル」を更新
　　 主にPAdESの LpaCmd の -client/-server オプション関連の更新
　→ 証明書選択時の情報表示に「拡張キー用途」を追加
　→ 初期化時のフラグとして拡張キー用途をチェックする機能を追加
　→ Windows証明書ストアにCNG形式で登録された秘密鍵に対応

■ 修正項目：
　→ 新規Windows環境で署名コマンドの実行に失敗する場合の修正

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

実は今C#を使ったプログラムを使っている。C#を使えばMSの世界にどっぷりハマる事は明確なのでこれまで正直言って避けていたのだ。しかし仕事とあっては避けてばかりもいられないので色々と勉強をしている(^^;

最初の難関はGUI部だ。Visual-C++でMFCを使った開発ならもう10年選手なのでお手の物。でもC#を使ったイベントドリブンなGUI開発は今更食指も動かないし細かなノウハウも使え無いのでパスしたいところ。ならC++（ネイティブコード）からC#（マネージコード）が使えれば良い。私のC#に関する知識はJavaの真似っ子と言うレベル。Javaはバイトコードと呼ばれる中間コードを仮想マシンＶＭで実行するが、C#はマネージコードと呼ばれる中間コードになるだけだろうと。JavaならJNIを使ってネイティブコードとインターフェイスを取るがC#だとDllImportを使えば良いのかと考えていた。ただ今回必要なのはネイティブコードから中間コードを使いたいので本当は逆向きだ。実はちょっと面倒だなと敬遠しかかっていた。

ところが先方から「Visual Studio .NET 2003のC++マネージ拡張」と言うのがあるがどうだ？とのメールが。チェックして見るとうわ～何だこれは(^^; .NET 2003ではC++マネージ拡張となっているが、最新のVisual Studio .NET 2005 を使えば C++/CLI と言うC++を拡張してマネージコードを吐ける規格が出来ているでは無いか。しかも１つのソースファイル中でも#pragmaを使ってマネージコードとネイティブコードが使い分けられる。さすがMS節操が無いぞ（笑） しかもフレームワークとしてもMFCと.NET Frameworkが同時に使えてしまう。何でもアリやなあ… Java環境だとネイティブのインターフェイスはJNIだけなので使いにくいがこれも色々理由があってそうなっているので、MSの実装が素晴らしいのかとんでも無いのかは立場によって異論があるところでしょう。

と言う事で細かな技術的な問題点はあるもののとりあえずネイティブコードとマネージコードの混在は可能なようだ。C++/CLIが使えるのは Visual Studio .NET 2005 からなので、これからは2005を中心に使うか。でも C++/CLI なんてのが動いてしまうと C# の立場はどーなる(^^;;

あと注意が必要なのはC++/CLIはC++の拡張であって上位互換しか無い点と、ソースはほぼ同じに見えるがC++/CLIだとマネージコードになるのでメモリ管理が従来のネイティブコードのC++とは全く別物になるので気をつけないとコンパイル時にエラーになる辺り。この辺りの注意点なんかはまた時間を見て書きたいと思います。とりあえず今日はこの辺りまで。

以前にC++でboost::shared_ptrを使ってインターフェイスクラスを書くと言う事を書いたが、今回はそれのC++/CLI版。C++/CLIでは新たに interface が導入されJavaライクなインターフェイスが定義できるようになっている。またC++/CLIのマネージコードではガベージコレクションされるので gcnew と生成すれば破棄は自動的に行われるのでboost::shared_ptrも不要だ。早速サンプル。

// インターフェイスクラス
interface class IName {
public:
　virtual String ^ getName();
};

// 実装クラス
ref class Name : public IName {
public:
　Name( const std::string name )
　{
　　a_name = gcnew String( name.c_str() );
　}
　virtual String ^ getName()
　{
　　return a_name;
　}
private:
　String ^ a_name;
};

// ファクトリー関数
IName ^ makeName( const std::string name )
{
　IName ^ name_ptr = gcnew Name( name );
　return name_ptr;
}

// 使い方
void printName()
{
　std::string myname = "miyachi";
　IName ^ name_ptr = makeName( myname );
　Console::WriteLine( "Name = " + name_ptr-
}

C++/CLIのマネージコードの世界ではStringを使う。内部はJavaと同じくユニコードになるので単純にcharポインタには変換できないので注意が必要。charポインタを使って初期化は出来る。

サンプルを見ると判るが、インターフェイスクラスにはinterfaceを付けて宣言をして、実装クラスにはrefを付けてマネージコードである事を宣言しておく。ただ細かくは実装クラスのメンバメソッドにもvirtualを付けなければいけなかったりする。

このサンプルを見るとC++/CLIと言うのはもう従来のネイティブなC++とは別物だと判る。コンソール出力もstd::coutだと.NETのStringが使え無いのでConsole::WriteLineを使わねばならない。

C#はマネージコードだけで済むなら便利だ、C++/CLIはネイティブコードとマネージコードの混在が可能なのが便利だ、ただしいずれにせよC++な世界とは言えないので移植性面では多大な問題があるだろう。C#やC++/CLIがどこまで広まるかが鍵となるが、.NET環境以外でこれらの言語を使えるようになるのだろうか？ちなみにMacOSの世界だとまた別言語となるObjective-C++なんてものもあるんだが… 困ったもんですねえ(^^;

相変わらずC++/CLIとの格闘の日々（笑） 細かな点はおいといてだいぶ使えるようになってきたので、少し本格的に古いGUIから .NET Framework を使おうとしてみた。古いGUIとはMFCのCDialogをベースとしたクラスだ。つまり

// マネージクラス
ref class ManageClass {
public:
　bool dotnet();
};

// ネイティブクラス
class NativeClass {
public:
　NativeClass()
　{
　　m_manage = gcnew ManageClass();
　}
　bool test()
　{
　　return m_manage-
　}
private:
　ManageClass^ m_manage;
};

としてみたら見事にエラー…

1
1

う～む。なるほど理屈から言えばネイティブなクラスにマネージ管理されているgcヒープのオブジェクトは管理出来ないな… でもそれが出来なきゃ非常に使いにくい。MSから出ているC++/CLIの資料を見るも解決策が見えない。でもあのMSのことだ。どこかに卑怯な回避方法があるに違い無い！古いC++/CLI以前のマネージ拡張をチェックしてみた。…やっぱりあった（笑）

先に書いたように普通はマネージクラスへのポインタは、ネイティブ（アンマネージ）クラスのメンバ変数やグローバル変数には出来ない。でも gcroot テンプレートを使えば可能だとある。これはC++/CLIの規格外のようでC++/CLI関連の資料には載っていない。これを使って先のプログラムを書くと。

// マネージクラス
ref class ManageClass {
public:
　bool dotnet();
};

// ネイティブクラス
class NativeClass {
public:
　NativeClass()
　{
　　m_manage = gcnew ManageClass();
　}
　bool test()
　{
　　return m_manage-
　}
private:
　gcroot<ManageClass^> m_manage;
};

そう。ネイティブクラスのメンバ変数として使う場合にgcrootでマネージクラスへのポインタを囲うだけで良いのだ。なんて安易（笑） でもこのおかげで例えばMFCのCDialogクラスで .NET Framework のマネージクラスをメンバ変数に出来る。gcrootを使えば STL の vector でマネージクラスを扱えたりもする。更にマネージコードのポインタをネイティブコードから扱う為にアドレスをピン止めする pin_ptr と言う物も用意されている。こちらはC++/CLIでも説明がある（マネージ拡張では __pin だった）。いやさすがに何でもありのMSだ。卑怯ではあるが非常に便利。

よお～し！これで（だいたい）C++/CLIは使えるようになった！本来のコーディングを進めねば(^^;

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

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

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

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

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

前回の投稿もそうですが「プログラマの日記」なものでプログラム等のソースコードをブログに書く場合が多いです。しかし表示は手を抜いていたので見苦しいものでした。以前から何とかしなければと考えていましたが、お昼休みにエイヤッとやってしまったので記録です。

まずどういうやり方が一般的なのかググってみました。JavaScriptやPHPのプラグイン的にやるケースが多いようです。行番号が付けられたりして便利そうですが、プラグインを使うのはどうも好きではありません。そんな中で見つけたのがMTサイト構築Tips集様の以下の記事。

　pre、codeタグを使ってソースコードを美しく表示する

CSSを使って結構美しく出来るようです。早速参考にしてみてCSSにPREとCODEタグの定義を組み込んでみました。おお。結構綺麗。背景画像もこのブログ用に修正して…前回の投稿のソースも見やすくなったと思いますがいかがでしょうか？MTサイト構築Tips集様ありがとうございましたm(_ _)m

ただまだ問題があります。ソースを入れる場合にソースコードの特殊文字を変換する必要があります。まあこれは比較的簡単なのでJavaScriptで作ってみました。以下長くなるので続きを読むにて。 [続きを読む]

Visual Studio 2012以降で、.NETを使ったC++/CLIでXmlDocumentクラスを使った場合に実行時に以下のようなエラーになる事があります。

　「'System.Xml.BinaryCompatibility' のタイプ初期化子が例外」
　「'System.Uri' のタイプ初期化子が例外」

最初はWindows 8.1とWindows Server 2012だけの現象かと考えていましたが違いました。Visual Studio 2012以降に、C++/CLIを使った時に生じる問題でした。OSは無関係です。かなり悩んだのできっと同じ道を辿る方の為に原因と対処方法をまとめます。ちなみにこの解決方法は「ここ」で知りました。感謝感謝です！ [続きを読む]

日本語コードは最近のプラットホームではUnicodeに統一されつつあります。Java/MacOS-X/.NET等の環境では内部コードはUnicodeです。とは言えお仕事をしていたり古いコードが捨てられない場合にはどうしても旧来のShift-JISで文字列を取得する必要がある場合がまだまだ多いのも事実でしょう。メモ代わりに簡単に各種言語や環境でもUnicodeからShift-JISへの変換例をまとめます。

まずはJavaです。私も最初にUnicodeとShift-JISの変換が必要になったのはJava環境でした。またShift-JISと言っても細かく分けると色々ありJava環境でも混乱しています。ここではWindows環境で一般的な"MS932"をShift-JISとして扱った例を示します。JavaではShift-JISは文字列として扱えないのでbyte列として取得する事になります。

// ----- Java -----------------------------------------------
　// Unicode文字列をShift-JISに変換してbyte[]に格納
　String str = "日本語";
　byte[] sjisData = str.getBytes("MS932");
　// "MS932"はWindows用で"SJIS"が本来のShift-JIS
// ----------------------------------------------------------

次に最近やったばかりのCocoa/Objective-Cの環境での変換。Objective-CでもShift-JISは文字列として扱えないのでNSDataとして取得します。しかしObjective-Cって何でこんなに１行が長くなるかな（笑） ちなみに [str cString]; でも const char * のポインタ取得できますがこれは使わない方が良いそうです。

// ------ Objective-C ---------------------------------------
　// Unicode文字列をShift-JISに変換してNSDataに格納
　NSString* str = @"日本語";
　NSData* sjisData = [ str
　　dataUsingEncoding:NSShiftJISStringEncoding　// SJIS変換指定
　　allowLossyConversion:YES　// 変換不能でもとにかく変換
　];
// ----------------------------------------------------------

最後はWindowsの.NET環境と言う事でC++/CLIでの例をおまけとして。幾つか試してみましたが結局はMFC/ATLのCStringを使って変換するのが一番簡単で間違いが無いようです。

// ------ C++/CLI (おまけ) ----------------------------------
　// マネージコードUnicode文字列を変換してMFCのCStringに格納
　String^ str = L"日本語";
　CStringA sjisStr = str;　// 手抜きだけど一番楽かと…
// ----------------------------------------------------------

あと最近はXMLだとUTF-8形式が一般的ですね。内部コードはUnicodeでXMLはUTF-8がこれからの標準でしょうか。本来は上記のようなコード変換は不要になるが一番なので、ぼちぼちと移行して行きたいですね。

iアプリの開発をするとやはり一番困るのが100KBのサイズ制限でした。次の903iシリーズからは久しぶりにこのサイズが緩和される事になったようです。

　ITmedia：ドコモ、「903i」シリーズ向け大容量iアプリ「メガiアプリ」を発表

従来は本体100KBに保存領域400KBの合計500KBだったものが、903i以降のメガiアプリでは両方の区別が無くなりトータル1MBまで許されるとのこと。実質としては２倍の領域拡大ではありますが、保存領域との区別が無くなった事もありエンタープライズ系のiアプリ開発時には朗報です。ところで先日開発したiアプリは外部メモリ(miniSD)への保存機能を使った。これに関しては

外部メモリにデータが保存できるのは一部の機種（「P902i」「902iSシリーズ」「DOLCE SL」「N902iX HIGH-SPEED」）に限られていた。

とあるのだが… えーとつまり902iSシリーズならＯＫと言う事で別に903iシリーズ以降の特長では無いと思うのですが(^^; 903iシリーズでは他にも機能アップ（一部の機種だけの機能だったものが標準搭載）があると聞いています。なんだかiアプリも本格的なアプリ開発が出来そうな環境になってきたように思います。

携帯アプリと言うと他にもC++をベースにしたBREWアプリがありますが、私的にはJava系の方がBouncyCastleが使える事もあり慣れてきているのでメガiアプリには期待です。1MBあれば公開鍵暗号も使えるかも。ちなみにiアプリ開発にはeclipseも使えてデバッグ環境も揃っているので結構便利です。

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

■ 新機能：
　→ 最後の署名後の更新を判定する LePAdES::isUpdate() を追加
　→ 署名外観に所有者別名を利用するオプションを追加
　→ Windows版においてSIGSEGV時の例外をcatchしてthrow機能の追加
　→ clientV2 フォルダの下を、クライアント署名V2.1.R2 に更新
　→ LpaCmdの -client がLinux版でも動作するように修正
　→ LpaCmdの -server で要求XMLを標準入力から指定出来るように修正
　→ LpkTimestampTokenクラスに addValidationData() を追加。

■ 修正項目：
　→ PDF内部のHEX文字列の途中で改行がある場合の問題の修正
　→ DSS辞書が既にある場合のaddLTV()時にDSS辞書が更新されない問題の修正
　→ 署名済みPDFに対し添付ファイル追加が実行された場合にエラーにする修正
　→ PDFのMediaBoxのx1/x2かy1/y2が逆でも正しく位置を指定を可能にする修正
　→ Object Stream 解析時の最大バッファサイズの指定に誤りがあったので修正
　→ 未使用のPDFオブジェクトがあった時に誤動作する場合があったので修正
　→ xrefの情報が誤っている不正PDFの場合に例外となる場合があったので修正
　→ ByteRangeの情報が誤っている不正PDFの場合の問題の修正
　→ 署名情報が誤っている不正PDFの場合に例外となる場合があったので修正
　→ 証明書の所有者別名が正しく取得出来ない場合があったので修正
　→ .NETのAPIにおいてsaveEmbedFileにてユニコードの問題を修正

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

XML長期署名ライブラリLE:XAdES:LibをV3にバージョンアップしました。V2まではきちんとしたマニュアルを提供していませんでしたが、V3ではきちんとマニュアルを作成しました。参考の為にLE:XAdES:Lib V3マニュアル公開中です。

PDF長期署名ライブラリLE:PAdES:Lib（LE:PAdES-Basic:Lib含）もマニュアルをバージョンアップしています。またPKI基本ライブラリLE:PKI:Libに関してはLE:XAdES:Lib V3と共通化したことでマニュアルを分けました。

＞現在以下の製品マニュアルを公開中です。
〇PAdES：LE:PAdES:Lib/LE:PAdES-Basic:Libマニュアル(PDF長期署名)
〇XAdES：LE:XAdES:Lib V3マニュアル(XML長期署名)
〇PKI(共通)：LE:PKI:Libマニュアル(証明書やタイムスタンプの利用)
〇クライアント署名(オプション)：LE:Client:Signマニュアル(ブラウザ連携)

製品説明が主目的ですがPAdESやXAdESの説明もありますのでよろしければご覧ください。また製品検討時の参考資料としても自由にご利用ください。なお評価版にもマニュアルは同梱されています。

GPLのv3が草案と言う形で出て来ている。将来FSFのGNUプロダクトには適用されて行くのだろう。これはラング・エッジ的には凄く影響がある内容になっている。それはDRMに関する記載があるからだ。

　DRMやソフト特許に対処したGPL 3の草案

以下抜粋：
「DRM技術を実装した非フリーソフトは、ユーザーが法律で認められているはずの権利を奪いかねない牢獄だ。われわれの目的は社会慣行としてDRMを廃絶することであり、それを目的としなければならない」（FSFの文書より）

うちではDRM技術を使ったソフトを開発している。確かに何かを制限する技術ではあるので全てがフリー（自由）で無ければならないと言うFSFの精神には反するのかもしれないが、世の中には公開できない情報もあるとは思う。とは言えGNUプロダクトを開発しているFSFがこう決めるのだから我々としては当然従わねばならないし、それに対して残念ではあるが文句を言える立場では無いのも当然である。草案が採用されたらGPLのv3ライセンスのソフトはDRM関連のプロダクトには一切使用しないようにするしか無い。

さて今日の記事で、期待はしていたがLinuxカーネルはGPLのv3を採用する予定は無いようだ。良かった(^^;

　「LinuxはGPL 3に切り替えない」トーバルズ氏が表明
　追記：L・トーバルズ、「GPLバージョン3」に難色

以下抜粋：
「例えば、自分の非公開署名鍵を公開してくれと要求するのは正気の沙汰ではないと思う。わたしだったら絶対そんなことはしない」（Linuxカーネルのメーリングリストより）

LinuxカーネルはＯＫかもしれないが一番の問題はGCC(GNU-C++)関連やgmakeのようなGNUツールをどうするかだろう。うちもLinuxサーバで稼動している部分がある。少し対応方法を考えてみた。

　１）IntelのC++コンパイラを使う
　２）C++は使わないで全てJavaにする
　３）Windowsサーバを使ってVC++を使う
　４）SolarisなんかのUnixやBSD系に乗り換えてGCC他は使わない

くらいだろうか。最初のIntelコンパイラを使う方法が一番面倒が無い。価格はシングルユーザで57,750円だ。商用に使うコンパイラなのだからこの価格でも全くＯＫだ。ただgmake他のGNUツールも利用不可だとすると開発環境もまるまるどうするか考える必要があるだろう。切り分けが明確にならないかもしれない。Eclipseを使えば良いのかな？あれはCPL（Common Public License）だし。

最悪は２）以降の選択肢も検討しておくべきなんでしょうね。意外にSolarisが見直されたりして（笑） BSD系と言えばMacOS-XもそうなのだがこれもGCCが標準で入っている。Tigerには標準でGCC4.0が採用されている。

しか～しiTMSで売っている楽曲にはFairPlayと言うDRMが採用されている。従ってGCCを使っているとアウトになると思われる。ただし今後IntelMacに切り替わってしまうと、事情は変わってくるだろう。なぜならIntelMac用には先に書いたIntelコンパイラが提供されるからだ。

　米Intel，IntelMac向けのFORTRANとC++コンパイラなどのベータ版を公開

う～むMacOS-X用のIntelコンパイラは無償（Xcodeに含まれる）なのだろうか？それとも最終的には別売になるのかな？無償で付いて来るならUnix系メイン開発環境をIntelMacにするのも良いかもしれない。うむ。IntelMacを購入する理由が出来そうだぞ！

Linuxも場合によってはGPLのv3ライセンスを使わないディストリビューションが出てくるかもしれないし焦らず進展を見守りつついつでも切り替えが出来る準備を進めようと考えています。

最終的には脱GPLプロダクトになるのかもしれません。ただGPLプロダクトからは色々と助けられてきたしありがたく使わせて頂いています。どのような結論になっても感謝の気持ちは忘れません。貢献できなかった点はとても残念ではありますが… さてさてどれ程のソフトがGPL v3に切り替わるのでしょうか、GPL v3自体もどうなるでしょうか。見守りましょう(^^;;

[2006-02-02追記]
＞意外にSolarisが見直されたりして
などと書いていたが、以下の記事が。

　Sunのシュワルツ社長がGPL 3の採用を示唆

う～むそうですか(^^;;

アンテナハウス開発のサーバベース・コンバータ（SBC）を使うとPDFやOffice文書をFlash形式に変換出来ます。このFlash文書はMovieClipとして扱うことが出来るようになっています。弊社ではリッチなGUIを付けて、SBC出力のFlash文書を表示できるFlash文書フレーム「LeFlashFrame」を用意しています。文書のFlash/SWF化にご興味がありましたらぜひご覧下さい。[続きを読む]にて長期署名で公開済みの文書をFlash化したサンプルもご覧頂けます。 [続きを読む]

C++/CLIを使っているので最近はすっかり Visual Studio 2005 をメインに使っている。ところが何度かあるソースファイルだけデバッガを起動するとブレークポイントが無効になる事があった。どうもソースが不一致と言っているようだがリビルドしても一旦こうなると駄目。CVSに上げたファイルを他のPCでソースだけ落としなおしても駄目。う～んと悩んでいてふと無効ブレークポイントの上にマウスカーソルを移動すると安易な解決法が出てきた。

Visual Studio 2003 には無かったと思うが、ツールメニューのオプションでデバッグのところに

「元のバージョンと完全に一致するソースファイルを必要とする」

と言う項目があり、とりあえずこれをオフにするとブレークポイントが再び利用可能になる。何台かの環境で再現していたので同様の事で悩まれている方がいるかもしれないのでブログに残します。

ところでこの現象は結構変だ。実はコメントなどに１バイト書き加えてしまえば再びブレークポイントが有効になるのだ！つまりあるパターン（ハッシュ値とか？）のソースファイルだけでこのソースの不一致だと思われてしまうようだ。これってやっぱりバグだよなあ…回避方法が判ったから良いけど。

あと考えられるのはC++を使っていて2005ではプロジェクトの文字セットがデフォルトでは「Unicode文字セットを使用する」になっているのを「マルチバイト文字セットを使用する」つまりShift-JISにしているせいなのかもしれない。

この現象ひょっとすると最新のパッチなどでは直っているのかもしれませんが、無視するオプションが存在すると言う情報でした。

もうリンクを張る必要も無い程ニュースサイトやＴＶで報道されていますが、ＭＳのビルゲイツが２００８年にＩＴ系の仕事からは引退するとの事。

う～む彼は１９５５年生まれなので私よりも６歳年上。でもたったの６歳だ。８年後に私は引退できる事は…あり得な～い（笑） いや生涯１プログラマを目指しているので引退したくも無いが… 負け惜しみに聞こえるよーな気も(^o^;;

一方アップルＣＥＯのスティーブジョブズも実はビルゲイツと同じ１９９５年生まれの同い年だ。こちらは２年と言わずバリバリ頑張りそうですね。

ビルゲイツと言えばやはり個人資産世界一な訳だが、貧乏さなら私も負けない。これからやる仕事は、C++/CLIとMacOS/Cabonとiアプリ…お金だけじゃ無くて器用貧乏もあるんかい…orz

2008-05-26に「.NET Framework のRSA署名用ハッシュアルゴリズム」を、2009-04-17に「続 .NET Framework のRSA署名用ハッシュアルゴリズム」を投稿して来ました。間がずいぶん空いてしまいましたが.NET FrameworkによるRSA-SHA2署名が出来るようになりましたのでまとめます。

まずいまだにWindowsXPだろうがWindows7だろうが単純に証明書に関連付いている秘密鍵をRSACryptoServiceProviderクラスとして取り出しても"SHA256"や"SHA512"を指定するとそのままでは「無効なアルゴリズムが指定されました。」と表示されます。これは標準で指定されている暗号プロバイダが PROV_RSA_FULL(1) の為です。PROV_RSA_FULLがサポートするのはSHA(SHA-1)までなので、RSA-SHA2署名が弾かれてしまうと言うことになります。ではRSA-SHA2署名すなわちSHA-2に対応した暗号プロバイダは何かと言えば PROV_RSA_AES(24) となります。PROV_RSA_AESはSHA-1とSHA-2の両方をサポートしています。署名を使いたいのに共通鍵方式のAESの名前が付く暗号プロバイダを使う必要があるのは軽い違和感がありますがまあ気にしないで使いましょう。

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

// 証明書から関連付いた秘密鍵の取得
X509Certificate2^ cert = certFind(Thumbprint);  // dummy
RSACryptoServiceProvider^ rsa = nullptr;
rsa = static_cast<RSACryptoServiceProvider^>(cert->PrivateKey);

// ProviderTypeをPROV_RSA_AESとしたCspParametersの準備
CspParameters^ csp = gcnew CspParameters();
csp->ProviderName = nullptr;
csp->ProviderType = 24;  // PROV_RSA_AES
csp->KeyNumber = static_cast<int>(rsa->CspKeyContainerInfo->KeyNumber);
csp->KeyContainerName = rsa->CspKeyContainerInfo->KeyContainerName;

// PROV_RSA_AESにて秘密鍵の再取得
RSACryptoServiceProvider^ rsa2 = gcnew RSACryptoServiceProvider(csp);

// 署名実行
array<Byte>^ sign = rsa2->SignData(data, HashAlgorithm::Create("SHA512"));

ご覧になっていただければお分かりと思いますがまず普通にPROV_RSA_FULLの秘密鍵を取得して、そこからKeyContainerName等のパラメーターをCspParametersに指定してProviderTypeを24のPROV_RSA_AESにして用意して、最後に鍵の再生成を行なえばOKです。ProviderNameは空でKeyNumberは指定（コピー）しないと駄目な場合があります。他にもコピーが必要なパラメーターはあるかもしれませんがこれで私が現在使っている範囲では大丈夫のようです。これで署名した署名データをOpenSSLで検証してみるとValidなので問題は無いと思います。

なお以前はXPでは駄目だろうと書いていましたが、Windows XP SP3 以降であれば上記のコードは問題無く実行できています。もちろんWindows 7等でも動作確認しています。

2010年問題の為にRSA-2048bitとRSA-SHA2署名への移行準備が必要です。弊社のLe-XAdESライブラリも上記修正済みなので間も無くRSA-SHA2対応版をリリースする予定です。.Net FrameworkによるRSA-SHA2署名の話があまり検索しても出てこないのでご参考になれば幸いです。完結編と書いてしまったので何かミスが無ければ良いのですが(^^;

2012-03-13更新：
「CryptoAPIによるRSA-SHA2署名」を書きました。

CodeWarriorを使ったお仕事をやってました。でもなぜかCarbonからCocoaのライブラリを呼び出して使いとうとうObjective-Cまで使って短い機能を実装。いやObjective-Cを本格的に使うのは私は実は初めてだったりして(^^; これまでにC/C++/Java/C#等は使ってきていたので同じように考えていたら全く違っていて少しびっくり。オブジェクト指向っぽい使い方です。例えば文字列オブジェクトにサイズをたずねるには、

　unsigned int len = [ strObj length ];　　// strObjの文字列長を取得する。

むう。これはかなり来てますね(^^; 他の言語だと "." や "-

あとObjective-CはC言語の拡張でコンパイラもgccを使っていますので、過去のC言語の利用も従来通り利用が、特に混在が可能になっています。この辺りは.NETで言えばC#よりもC++/CLIに近いかもしれません。C#の方がJavaに近いかも。それにしても最近は似て否なる言語が多くて困ったもんです（笑）

これだけじゃ情報としてつまらないので文字列に含まれる改行コードの変換した例を紹介しておきましょう。通常はNSStringと言うクラスを使って文字列を操作します。ただ置換などの機能を使う場合にはNSMutableStringを使います。

　NSMutableString *mst = [NSMutableString stringWithString:str];
　[mstr replaceOccurrencesOfString:@"\n" withString:@"\r\n" options:0 range:NSMakeRange(0, [mstr length])];

おや簡単(^^; でもあまりネット上に情報が無かったので参考まで。改行コードをDOS風に変換する時に利用しました。他にも幾つか参考になりそうなコーディングをしましたがまた今度ネタ切れの時にでも書きましょう。

「XML長期署名ライブラリLE:XAdES:Lib」をバージョンアップして V2.00.b1 としました。DLL化して.NETのAPIとして利用できるようになりました。追加された主な機能は以下となります。

　１） .NETのDLL化でC++/CLI以外にC#からの利用も可能
　２） コマンドラインで利用可能なLxaCmd.exeの提供
　３） XAdES v1.3.2/v1.4.1/v1.4.2仕様に対応
　４） 23bit版と64bit版の両方を提供
　５） アマノタイムスタンプサービス3161 Type-T対応
　６） C++/C#/コマンド利用のサンプルソースを提供
　７） ldap通信にOpenLDAPも利用可能になった
　８） 内部で直接タイムスタンプ付与するaddEsT()/addEsA()追加
　９） その他細かな機能追加や障害修正等

OpenSSLのモジュール等は「PDF長期署名ライブラリLE:PAdES:Lib」と共通化しました。実はLE:PAdES:Libとのモジュールを含めた統合も大きな変更点です。メンテナンス性が向上しました。

まだベータ版ですがテストしたいと言う方がいらっしゃいましたらご連絡ください。まあいらっしゃらないと思いますがw

Raspberry Pi（以後、RasPi）は皆様ご存じのようにIoT向けの小さなLinux環境を提供するミニPCです。LinuxはDebianベースのRaspbian（使い方はほぼDebian）ですが、IoT向けと言うことで色々拡張することが多くセットアップやLCD選択も一筋縄では行きません。と言うことで以下までのノウハウを残しておこうと言うことでとりま４回を予定しています。なおRaspbianのバージョンは現時点での最新である、2.1～2.3で動作確認した結果となります。また動作確認したRasPiは、RasPi 3/RasPi 2B/RasPi Zeroの3種類です。

　第１回：Raspbianのセットアップ手順
　第２回：Amazonで買えるミニLCDの選択
　第３回：RasPiでRails動作とFireWall設定
　第４回：RasPiのI2Cでサーボモーターを動かす

では第１回と言うことで、Raspbianをインストールしてsshでリモートログインするまでを以下簡単にまとめます。 [続きを読む]

C++/CLIを使っていてマネージのString文字列からconst wchar_tのポインタを直接取得する方法です。これって結局単純に PtrToStringChars で pin_ptr すれば良いだけのようです。つまり、

　String^ str = gcnew String("日本語文字列");
　pin_ptr<const wchar_t> pStr = PtrToStringChars(str);
　　：
　pStr = nullptr;　// 使い終わったらpin_ptrを開放しておきましょう

とやれば良い。ちなみにMSDNサイトでも「方法 : System::String の文字にアクセスする」で解説してあります。

実は今CAPICOMだけだった部分をWin32のCAPIでも使えるように機能追加中です。CAPIはアンマネージのAPIなのでマネージの文字列から直接ポインタ取得できないかと調べた１ポイント情報でした。CAPICOM使うと便利なんですがCAPICOMのDLLも過去に脆弱性が発見されたり更新が面倒だったりと依存しない方が便利なケースも多いように感じています。

現在開発中のプロジェクトはMacOS-Xで動作しているあるアプリをWindowsに移植するというもの。Windows版もC++とMFCなら経験もあるので簡単ですが、せっかくなのでC#と.NET FrameworkだけでGUIも作ってしまおうと初めて本格的にC#だけでアプリを開発しています。これがなかなか一筋縄では行きません（笑） まあでも経験値はアップしていると思うので頑張りどころです。

閑話休題。さて今週取り組んでいたのは以下のようなスマート検索のダイアログです。問題になるのはメインの検索条件を入力する部分です。プルダウンありテキスト入力ありボタンありと言う事で DataGridView クラスを使うことにしました。



これが思った以上に簡単には使えない！何の罰ゲームですか？と言う感じでした。まあ情報はあるんですが私には判りにくかったです。なのでここで簡単にポイントだけ押さえておこうと思います。以後興味がある方は [続きを読む] にて。 [続きを読む]

「XML長期署名ライブラリLE:XAdES:Lib」がバージョンアップして、V3.00.R1 となりました。今回はメジャーバージョンアップとなります。完全に新規開発されたので既存のV2との互換性はありません。V2と比較して追加された主な新機能は以下となります。

■ 互換性：
　・V3はV2までのAPIとの互換性はありません（ご注意！）
　・PKI部はLE:PAdES:Libと同じLE:PKI:Libの共通APIとなります

■ V3新機能：
　1) V3ではWindows版に加えてLinux版も提供
　　　＞ V2ではWindows版のみだった
　2) V3では.NET以外にJavaとC++(g++)のAPIも提供
　　　＞ V2では.NETとC++/CLIのみだった
　3) V3では同一XMLファイル内の複数署名に対応
　　　＞ V2では1ファイル1署名のみだった
　4) V3では多階層のManifest構造に対応
　　　＞ V2では1階層のみ対応だった
　5) V3ではPKI機能にLE:PKI:Libを利用(LE:PAdES:Libと共通化)
　　　＞ V2では独自PKI実装

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

なおAPIに互換性が無いこともあり、V2系のメンテナンスサポートは継続します。今後もV3系とV2系の両方をリリースします。ただし今後新機能はV3に実装されますので可能であれば移行もご検討ください。