ラベル Java の投稿を表示しています。 すべての投稿を表示
ラベル Java の投稿を表示しています。 すべての投稿を表示

2012/10/01

Androidで共通鍵暗号化でつまづいたので記録に残す

Androidで文字列をセキュアに保存したい場合、
暗号化してsqliteに保存するのがよろしいと思われる。

ここではAndroid自体のセキュリティがアレだとか、Rooted端末とapktoolがあればアレをこうしてアレ出来るだとかいう話はとりあえず置いとく。

まず以下のようなソースを書いた。

内容は、

  • 共通鍵の秘密鍵を生成している箇所のみ抽出。
  • DBに鍵が保存されていない初回はif文を迂回して生成ロジックで生成後DBに保存。
  • DB保存後はDBから復元する。
private final static String ARGOLISM = "PBEWithSHA1And256BitAES-CBC-BC";

private SecretKey getSecretKey()
throws NoSuchAlgorithmException, InvalidKeySpecException, NameNotFoundException {

   // check saved secret key is exist.
   byte[] savedSecretKey = DBHelper.readByteData(context, "hoge");

   if(savedSecretKey != null && savedSecretKey.length > 0){
      return new SecretKeySpec(savedSecretKey, ARGOLISM);
   }

   // generate new secret key.
   char[] pw = generatePassword();
   int iteratorCount = 1024;
   int keySize = 256;
   int saltLength = 8;
   byte[] salt = "00000000".getBytes();

   KeySpec keySpec = new PBEKeySpec(pw, salt, iteratorCount, keySize);

   SecretKeyFactory factory = SecretKeyFactory.getInstance(ARGOLISM);
   SecretKey secretKey = factory.generateSecret(keySpec);

   // here

   // save secret key.
   DBHelper.writeByteData(context, "hoge", secretKey.getEncoded());

   return secretKey;
}
※DBHelperはsqliteへの簡便なアクセスを提供するクラスとする。
ここで使用しているDBHelperの先にあるテーブルはマップのようにkey/valueのデータ構造をしているものとする。

上記実行したところ、
生成後のDBから読み出した鍵が暗号化した鍵とは違うとのExceptionが発生。
secretKey.getEncoded()の値をDB書き込み前と後で見比べてみても同じ。
ワケワカラーン

結局、Exceptionの原因はクラス差でした。
生成前 : com.android.org.bouncycastle.jce.provider.JCEPBEKey
生成後 : javax.crypto.spec.SecretKeySpec

<guchi>
両方共 SecretKey を実装してるんだから、うまく動いてくれよ。
後、com.android.org.bouncycastle.jce.provider.JCEPBEKey の太字部位が出力されるのってバグじゃないの?
</guchi>

解決方法は
secretKey = new SecretKeySpec(secretKey.getEncoded(), ARGOLISM);
を先ほどのコードのDB書き込み直前(コードの //here の箇所)に追加して問題解決。

注意:saltの値は上記では簡易てますが、本当に使う場合はきちんとランダム値を生成するように変更してください。

2008/06/19

[Java]JavaFXとJavaAppletとSwing

以下JavaFXを過大に期待していたものの叫びです。
お目汚しを失礼します。




2007年のJavaOneにてJavaFXが出ていた。
当時はFlahsのような外見にワクワクしたもんだ。

そんでもってJavaFXの時代がくるのだろうなぁ・・・
と思っていた。

時はたち2008年またしてもJavaOneでJavaFXを打ち出している。
オオ、そんなにJavaFXは凄いのかと思えてくる。

ちょっと業務も大人しくなってきたしいっちょJavaFX触ってみようか。

うーん、Swingよりは大分楽になった・・・
でもこれ、ただの新しいScript表記言語じゃないか。

JavaFXは何がしたいのだ?
Objectに対するActionListnerのAddをしなくてよくなったのは評価するが・・・


今サーバーサイドのフロント部分でウケル物は何か?
と質問されたらこう答える。

  1. 「プログラマが簡単にかっちょいいGUI設計が出来るもの」
  2. 「デザイナが自由にGUI設計出来るもの」

のどちらかだと思う。
プログラマはデザイン考えるのが面倒臭い。
よって作れば勝手にかっこいいデザインになるようなGUI設計ツールがほしい。

デザイナは自分の頭の中にあるカックイイものを表現出来るツールが欲しい。
既存のツール(イラレやAdobe系列のツールなど)と連携がとれる、
もしくはデータが流用できるなら尚宜しい。

プログラマの要求を満たすのは今現在で言えばFlexだろう。
JSPの感覚でタグを組んでいけば自然とカックイイGUIが出来上がる。

デザイナの要求を満たすのはActionScriptだろう。
これはプログラミングで、デザイナのお仕事では本来ないはずなんだが、
パイオニアの利点か、過去のノウハウが出来てるし
デザイナがActionScriptに挑戦するといった視点でのHPや本が腐るほど出ているし
そういう先輩もいっぱい会社にいるだろう。

嗚呼なんてことだ両方ともAdobeに牛耳られているじゃないか。

さてJavaFXだ!
かっこいいGUI用ライブラリは用意されているらしい・・・ほうほう
細かいデザインも出来るらしい・・・ほうほう

だが新規のJavaモドキScript言語なぞで組むというのがおかしい。
簡略化したいというならSwingプログラムのActionListnerあたりの挙動だけJavaScriptもどきに変えてやればいいだけのハズなんだ。
全部簡略化してどうする!
過去つちかったプログラマのJava経験が生かせないじゃないか!
覚えるのが難しいわけじゃない、Java以外に覚える必要があるのがうざったいのだ。
難しい挙動やデザインをしたいのならばJavaになる?
それは一番プログラマがしたくない仕事の一つじゃないか。

そしてデザイナが使うには簡単なコトしか出来ない!
難しいJavaの挙動を覚えれば自由にデザイン出来る?
ならば過去からのノウハウがたんまりつまったFlash!
ActionScriptを使うだろう!

なんだこのJavaFXは!RIAを用意したかったダケだろうGosling!

嗚呼!だからこそjavaFXを使ってやるさ、勉強してやるさ!
世界のSunだもの、もしかしたらはやる可能性があるかもだもの。
そしたらパイオニアとは言わないけれど、
からActionScriptを勉強するよりは先頭集団の中に食い込めるもの。