TrueCryptでディスクを暗号化 (3)初期設定後編

ボリュームの生成が終了したら、暗号化したドライブのマウントを行う。

上半分がマウント先(マウント後にここで設定したドライブレターを通してアクセスする)で、そこにどの暗号化ドライブをマウントするかを下半分の「ファイルの選択」「デバイスの選択」で設定する。
設定したら「マウント」を押すと、暗号化ドライブにアクセスができるようになる。

ソフト処理でAESをかけている割には、極端に遅くなる感じもせず、いい感じである。
課題は、パスワードやキーファイル(使う場合)をどうやって管理するか、というところだろうか。

<追伸>
実は TrueCrypt は日本語化がされている。
ダウンロードのページを下のほうにスクロールしていくと、「More Downloads」というのがあって、その中に language packs というのがある。そこをクリックすると、ソースコードのダウンロードリンクや language packs へのリンクがでてくるので、さらにそこをクリックする。

そうすると、言語ごとの language pack のダウンロードリンクがでてくる。これをクリックすると .zip ファイルがダウンロードできるので、それをダウンロードして展開すると、ローカライズのためのファイルのほかに、日本語マニュアルが出てくる

これらのファイルを TrueCrypt.exe のあるフォルダに置いて、TrueCryptを再起動する。メニューの「Setting」→「Language」で日本語を選ぶと日本語表示になる。

TrueCryptでディスクを暗号化 (2)初期設定前編

インストールが終わったので、初期設定を行う。​

起動すると、こんな画面になる。最初は、「Create Volume」で暗号化ディスクを生成する。

 

 
ファイルを仮想ディスクにするか、パーティション/ドライブ丸ごとかを選択する画面が出る。
今回はディスク丸ごと暗号化なので、
真ん中の「Encrypt a non-system partition/drive」を選択する。
一番下はシステムドライブを暗号化する場合に使うらしい。

 
普通の暗号化ボリュームにするか、さらにその中に暗号化ボリューム(2階層になる)を
作るかを選択する。強制的にパスワードを喋らなければならない状況になった場合に備えて、
ということらしいが、後ろめたいことをするわけではないので普通のものにする。

 
暗号化するボリュームの場所を設定する。「Select Device」でドライブレターが
選択できるので、それで暗号化するディスクを選択する。

ボリューム作成時にフォーマットをするかを選択。上が標準で、ボリューム作成時にフォーマット。
下は、初めて読み出した際に暗号化するらしいが、すごく遅いらしい。

暗号化のモードを選択。普通はAESでいいと思う。
「ベンチマーク」を押すと、下のように暗号化のパフォーマンス測定をしてくれる。

ベンチマークの結果

 
ボリュームのサイズを聞いてくるが、HDD丸ごと1台なので選択肢なし

 
パスワードを入力する。画面ではキーファイルを指定していますが、実際には指定していません。
(キャプチャし忘れました)
キーファイルを使うと、うっかりキーファイルを消去してしまった場合にどうにもならなくなります。
キーファイルの代わりに、特定のUSBデバイスが使えれば便利なんでしょうが・・

TrueCryptでディスクを暗号化 (1)インストール編

雑多なデータはやはりWindows上にあることが多いので、Windowsから暗号化できないと面倒である。仕方がないので、Windows側にTrueCryptを導入して、暗号化パーティションを作成することにした。TrueCrypt(http://www.truecrypt.org/)は「オープンソースの暗号化された仮想ディスクを作成・利用するソフトウェア」(Wikipediaによる)である。詳しくは、Wikipediaの方を参照されたい。

単純にWindowsであればOSの暗号化機能でも良さそうな気もするが、ディスク自体は外付けであり、過去にOSの再インストール時に読めなくなったことがある(このときは他にバックアップがあって助かった)ので、やっぱり外だしのツールのほうが安心かも、ということである。

そんなこんなで、まずダウンロードする。TrueCryptのダウンロードのページにいくと、ダウンロードのリンクとPGP signatureのリンクがある。ダウンロードしたファイルの検証方法は PGP Signature のリンクを押すと表示されるが、Windows版の場合は電子署名を確認してもOKだよ、ということみたいである。よって、ダウンロードしたファイルをエクスプローラで右クリックして、プロパティを表示して確認していく。

プロパティを開いたところ。デジタル署名のタブをクリックする。

 

すでに選んであるが、TrueCrypt Fundation の署名を選択して「詳細」を押す

 

ここで「このデジタル署名は問題ありません」と出れば、OKみたいである。

引き続き、実行形式のファイルをダブルクリックして、インストールを行う。

お約束のライセンス確認である。中身を読んでチェックを入れて「Accept」を押す

 

インストールするのか、展開だけなのかを選ぶ。
展開だけを行う場合は、「システムドライブの暗号化を行う場合」と
「ポータブルモードで動作させる場合」のようである。
展開したファイルの実行形式をダブルクリックすると
ポータブルモードで動作するらしい。

 

セットアップオプションを選ぶ。標準のままにした。

 

インストールの過程が表示される。
完了すると、完了のメッセージが出る。

 

「初めて使うんだったら、チュートリアルを読むことをお勧めするよ、
チュートリアル見たい?」ということなので、「はい」を押す。

 

「はい」を押すと、TrueCryptのチュートリアルのページが開く

ということで、インストール自体はいたってシンプル。あっさり終わりました。

Ubuntuでディレクトリを暗号化

この時期になると、年賀状などを書かなくてはならないだが、年賀状は個人情報の塊でもある。

これまではNAS(玄箱PRO+Debian)に保管していたが、結局無防備な状態であった。調べてみると、Ubuntuでも暗号化ディレクトリが作れるということなので、試してみることにした。
  1. Cryptkeeperのインストール
    Cryptkeeperは、暗号化ディレクトリを生成する encfs のGUIとのこと。
    例によって、Synapticでサクッとcryptkeeperを検索して、インストールする。
  2. 適当にディレクトリを2つ作る。1つは暗号化されたディレクトリの実体(データ格納場所)、もう1つは暗号化されないデータを見せるマウントポイント。
    ここでは、/home/encryptedが暗号化されたデータの格納場所、/home/enc-mtptがマウントポイントとした。それぞれ、chown コマンドで group/owner を自分に変えてある。
  3. 以下の方法で暗号化されたディレクトリを実体にマウントする。

    これで /home/enc-mtpt にアクセスすると、暗号化されたデータにアクセスできた。
  4. アンマウントは

    でアンマウントできた。

・・・が、ここで問題。EncFSで mount したディレクトリは、どうやら共有できない模様。Windowsからアクセスするディレクトリにするつもりだったので、ガックリである・・・。

PIC24USBでUSBシリアルに挑戦 (4)送信バッファ組込み

アナライザとしてPIC24USBを使う場合、大量のデータがPIC24USBからPCに上がってくることになるが、Microchip社が提供するUSB Frameworkでは送信バッファがそのままUSBコントローラに渡されるため、送信データは毎回ブロッキングされてしまう。これではちょっと都合が悪いので、ソフトウェアのバッファを噛ませることにした。
1KBのソフトバッファをかませたうえでのUSB-CDCの通信速度は約200~250Kbpsといったところのようである。PIC24USBからSOF割り込みの回数カウント値とデータ表示回数をカウントした値をsprintfで表示したものを、PC側でTeraTermProでひたすら表示しているだけである。
XBeeとAVRの間は9600bpsなので、上り下りで約20Kbpsである。凝った解釈をしなければなんとか表示できると思うのだが・・・。

VMware上にUbuntu10.04LTSとXubuntu10.10をインストール

Chromeブラウザのアルファ版を試してみたくなった。しかし、普段の環境にインストールすると後で往々にしてハマることが多いので、VMware上にインストールすることにした。

まずは、Ubuntu10.04LTSをインストール。インストールISOイメージを持ってくる(ダウンロードする)間に、仮想マシンを debian32bit で生成。仮想CDROMにインストールISOイメージをマウントして、仮想マシンを起動。インストールISOイメージを仮想ディスクとは別のHDDにいれていることと、仮想ディスクへのライトキャッシュを許可してあることからか、インストールはあっという間に終わってしまう。次に、アップデートマネージャを起動すると、数百MB分のアップデートが要るということで、かなりの時間を要してしまった。
VMware toolsのインストールも、共有ディスクを生成していないことでエラーが出るのと、vmxネットワークドライバのコンパイルでエラーになるが、操作性とグラフィックスの改善ができたのでよしとする。(しかし、実際には、VMwareについているVMware toolsよりも、ここで紹介されているopen-vm-toolsの方が良いのかもしれない。)
それはさておき、Ubuntuのインストール中に見つけた、軽量版のXubuntuが気になってしまった。(Ubuntuでも十分に軽いのだが)
同様にインストールISOイメージを持ってくる(ダウンロードする)間に、仮想マシンを debian32bit で生成。仮想CDROMにインストールISOイメージをマウントして、仮想マシンを起動。インストールISOイメージを仮想ディスクとは別のHDDにいれていることと、仮想ディスクへのライトキャッシュを許可してあることからか、インストールはあっという間に終わってしまう。こちらのインストール時は繁体字(中国語)まじりの日本語になっているが、インストール後の日本語の文字はUbuntu10.04と大差は無い。(ただし、メニュー自体は一部英語のままになっている)
次のアップデートもUbuntuと同様だったが、その次のVMware toolsのインストールで嵌ってしまった。結局、調べていくと、VMwareについているVMware toolsではなく、ここで紹介されているopen-vm-toolsを

$ sudo apt-get install open-vms-tools

でサクッとインストールするだけでよいことがわかった。
次にChromeブラウザをインストールした。デスクトップやランチャメニューに追加するには、Ubuntuの場合にはマウス操作でできたのだが、Xubuntuはそうはいかず、ランチャを一つずつ追加するしかなさそうである。
機能的にはやや劣るものの、XubuntuはUbuntuと比べても非常に軽い。そして概ね日本語化ができていて、フォントも(インストーラを除けば)Ubuntuのものと同じ綺麗なものが使われている。・・・と思ったら、XubuntuでChromeを使うとUIと異なるちょっと貧相なフォントが使われてしまうのが残念。Chromeの設定自体は同じようなので不思議なのだが・・・。


12/23追伸
Chromeのアルファ版はWindows版しかないのであった。がっくり。

PIC24USBでUSBシリアルに挑戦 (3)ソースを改造してみる

USB Frameworkは無事に動作したのだが、ループの中で常にCDCTxService()を呼び出し続けなければならない構造になっていて、改造しにくい。できればそんなものは割り込みなどで監視してほしいものである。

なので、もう少しコードを眺めてみることにした。そこでわかったこと、試してみたことは、

  • usb_config.h の中に、
    #define USB_INTERRUPTがあり、PIC24FJ256GB106ではUSBは割り込みで動作している。
  • main.c の最後に、BOOL USER_USB_CALLBACK_EVENT_HANDLER()という関数があり、そこでUSB割り込み発生後のユーザー用のハンドラを記述できる。
    EVENT_TRANSFERがパケット転送後、EVENT_TRANSFER_TERMINATEDがパケット転送中断後のイベントのようである。Start of Frame は EVENT_SOF
  • 問題の面倒くさい処理 CDCTxService()は、usb_function_cdc.c の最後にある。
    細かくは見ていないが、USBHandleBusy(CDCDataInHandle)を確認し、BUSYでなければ送信データをエンドポイントのサイズに分割しながらメモリ中にコピーして、USBTxOnePacket()を呼び出している。このUSBTxOnePacket()は、usb_device.h の中で
    #define USBTxOnePacket(ep,data,len) USBTransferOnePacket(ep,IN_TO_HOST,data,len)
    となっている。
  • putUSBUART()は、mUSBUSARTTxRam()を呼び出している。その際、cdc_trf_stateがCDC_TX_READYかどうかをチェックしていて、CDC_TX_READYでない場合には、何もせずに帰ってくる。即ち、送信しようとしたデータは捨てられることになるが、事前にUSBUSARTIsTxTrfReady()をチェックしていれば、そのようなことは起きないはず。
  • cdc_trf_stateはエンドポイントの初期化でCDC_TX_READYにセット、CDC_TX_COMPLETINGの状態でCDCTxService()が呼ばれるとCDC_TX_READYにセット、mUSBUSARTTxRam()などを呼ばれるとCDC_TX_BUSYにセットされるようである。整理すると、「CDC_TX_READY」→「(送信データセットで)CDC_TX_BUSY」→「(データの終わりのZeroLengthPacket送信で)CDC_TX_ZLP(省略あり)」→「CDC_TX_COMPLETING」→「CDC_TX_READY」となるようである。
  • mUSBUSARTTxRam()は渡されたデータのポインタ(アドレス)、長さなどをモジュール内のグローバル宣言の構造体や変数などにコピーするだけ。実際の転送処理はCDCTxService()に任される形になる。

つまり、putUSBUART()などから送信データをポインタ渡しされたら、そのポインタをコピーしておき、CDCTxService()が呼ばれる度に状態をチェックして、送信データをエンドポイントのサイズに分割しながらコピー、送信する、という動作のようである。

これらのことから、以下のようにすれば概ね上手く行くのではないかと考えた。

  • 送信データをセットする前に、USBUSARTIsTxTrfReady()をチェックして、CDCTxService()が抱えている未送信データの有無をチェックする。(CDC_TX_READYかチェックする)
  • 送信データを準備し、putUSBUART()でそのポインタを教えてやる
  • その直後に、一度だけCDCTxService()を呼び出し、送信を開始する。CDCTxService()はデータをエンドポイントのサイズに切り出して最初のパケットを送信する。
  • USER_USB_CALLBACK_EVENT_HANDLER()の中のEVENT_TRANSFERのところに、CDCTxService()を追加して、1パケット送信ごとに自動的にCDCTxService()が呼ばれるようにする。割り込み処理内なのでネストしてしまうリスクがあるが、USBUSARTIsTxTrfReady()を実行してから送信処理をしていれば大丈夫なはず・・・。

ということで、実際に試してみた。確認のため、usb_config.hの

#define CDC_DATA_OUT_EP_SIZE 64
#define CDC_DATA_IN_EP_SIZE 64
を共に4に変更してみたところ、送信(PCから見ると受信)に関しては問題ないようである。
しかし、逆方向はファイルを流し込むと送受信を同時に行った際にデータを取りこぼしてしまう。もう少し調べなければ・・・。

PIC24USBでUSBシリアルに挑戦 (1)準備編

ずっと前に買ったオプティマイズのPIC24USBを引っ張り出してきた。
このボードに搭載されているPIC24FJ256GB106にはUSBデバイスインタフェースとシリアルポートが4チャンネルあるので、これらを使ってシリアルラインモニタを作ろうと考えている。シリアルラインモニタを使って、XBeeのプロトコルをモニタする作戦である。

USBプロトコルの処理は、Microchip Technology社から提供されているMicrochip Application Librariesの中のUSB Frameworkを使うつもりである。Microchip Application Librariesは、MicrochipのホームページのSoftware Librariesの中からダウンロードできる。

ダウンロードしてインストールすると、Microchip Solutionsというフォルダができるので、その中の「USB Device – CDC – Basic Demo」フォルダの中の、「CDC – Basic Demo – Firmware」フォルダの中の、「USB Device – CDC – Basic Demo – C30.mcw」をダブルクリックすると、MPLABが立ち上がり、プロジェクトが開く。

ここで、「Configure」→「Select Device」でPIC24FJ256GB106を選択し、さらに「Project」→「Package in .zip」を選択すると、ビルドに必要なファイルだけが「USB Device – CDC – Basic Demo – C30.zip」という名称でZIPに圧縮して保存される。これを別のフォルダで展開したものを作業のベースとすることにした。

試しに、「Project」→「Build All」すると、ちゃんとHEXファイルが生成されることを確認できる。

PIC24USBでUSBシリアルに挑戦 (2)サンプルソースを動かしてみる

まず、回路図を比較してみる。後述の通り、PIC24FJ256GB106を使うボードのターゲットはPIC24F Starter Kitである。こいつの回路図はMicrochip社のWebサイトで入手できた。PIC24USBとの主な差分は、

  • Starter Kitのクロックは、PIC18F67J5(デバッグ用のPICか?こいつのクリスタルは12MHzとなっている。)から供給されているので、周波数がよくわからない。一方で、PIC24USBのクリスタルは16MHz。
  • Starter Kitには32kHzのクリスタルがついている。
  • Starter KitはPGEC2/PGED2にICSP端子がつながるようになっているが、PIC24USBはPGEC1/PGED1にICSP端子がつながるようになっている。

であった。さらにソースを一通り眺めてみた。

  • 「main.c」からは「HardwareProfile.h」がインクルードされている。
  • 「HardwareProfile.h」を見ると、PIC24FJ256GB106を選択すると「Hardware Profile – PIC24F Starter Kit.h」がインクルードされることがわかる。
  • 「Hardware Profile – PIC24F Starter Kit.h」をみると、91行目で「PIC24F_STARTER_KIT」がdefineされる。
  • 再び「main.c」を見ると、213行目でCONFIGビットの設定が記述されていることがわかる。
    _CONFIG1( JTAGEN_OFF & GCP_OFF & GWRP_OFF & COE_OFF & FWDTEN_OFF & ICS_PGx2)
    _CONFIG2( 0xF7FF & IESO_OFF & FCKSM_CSDCMD & OSCIOFNC_ON & POSCMOD_HS & FNOSC_PRIPLL & PLLDIV_DIV3 & IOL1WAY_ON)

    CONFIG1は、JTAG禁止、コードプロテクトOFF、ライトプロテクトOFF、Clip-on Emulatorイネーブル、ウォッチドッグタイマOFF、さらに「ICS_PGx2」でPGEC2/PGED2とICSP端子をシェアする設定になっているので、ここを「ICS_PGx1」に変更する必要がありそう。
  • CONFIG2はTwo Speed Start UpがOFF、Clock Switch & Monitorが両方OFF、OSCO端子機能はRC15、HS oscillator、Primary oscillarot w/ PLL、RPレジスタへの書込み制限無しで、さらに「PLLDIV_DIV3」はオシレータの周波数が12MHzの時の設定だから、ここは「PLLDIV_DIV4」へ変更が必要と思われる。
  • 再び「Hardware Profile – PIC24F Starter Kit.h」をみると、95行めから122行目でデモボード上のLEDやスイッチに関する入出力の記述がある。

ということがわかった。

そこで、「HardwareProfile – PIC24F Starter Kit.h」の94行めから123行めのLEDとSWのマクロ定義の中身を適当に修正する。ポート読出し用は0か1固定、ポート書込み用は中身を空にすることにした。この状態だと、「main.c」のProcessIO()関数の中身によれば、入力されたASCIIコードに1を足したものをエコーする(つまり、AをタイプするとBを表示する)プログラムとなるようだ。

修正してコンパイルしたところ問題なくコンパイルが通ることが確認できた。

これをPICkit2で書き込んでリセット解除すると、新しいCDCクラスのデバイスとして認識され、「USB Device – CDC – Basic Demo」フォルダの下の「inf」フォルダ内のinfファイルをインストールすると、COM12ポートが生成された。TeraTermでCOM12を開いて、キーを入力すると、期待通りタイプしたキーのASCIIコードに1を足した文字が表示された。

ATmegaとのシリアル通信~AVRLibのtimerのテスト

同様に、AVRlibのタイマーのテストを行いました。修正箇所は、

  1. プロジェクトディレクトリの global.h のCPU動作周波数を8MHzに修正
  2. プロジェクトディレクトリの Makefile のROM書込みに関する部分を追加変更前は、

    変更後は、
  3. 同じく Makefile のソースファイルに関する部分を変更
    変更前は、

    変更後は、
  4. 同じく Makefile の依存関係に関する部分を変更
    変更前は、

    変更後は、

結局、タイマー周りの修正が要る、ってことですね。
これで一応シリアルの表示上は動いている(ポーズもそれっぽく掛かっている)気がするのですが、PWM出力の方は出ていないようです。
この辺はまた今度にすることにします。