2011年6月13日月曜日

ソニーがAESに対応したFeliCaをチップを発表

ソニーがAESに対応したFeliCaチップを発表しました。サヨナラ3DES。以下、日経BPの記事より引用です。
ソニーは2011年6月10日、暗号方式としてAESを採用し、メモリ・サイズを6Kバイトに拡張した次世代FeliCa用のICを開発したと発表した。現行品は暗号方式がトリプルDES、メモリ・サイズが4Kバイトだった。2011年冬にサンプル・チップの出荷を開始し、2012年春から量産出荷する予定。

暗号の業界で良く言われる言葉に、「弱い暗号を使うならば、暗合化しない方がよい」というものがあります。これは、暗号化したことによって、セキュリティが高くなったと思い込み、逆に秘密データの管理を疎かにしてしまうことを意味しています。

で、「そろそろヤバそうな暗号アルゴリズムを使うの止めようよ」というのが、俗にいう暗号2010年問題です(2010年は過ぎちゃったけど)。今回FeliCaが採用するAESは2010年問題の言い出しっぺのNISTが推奨する共通鍵暗号アルゴリズムに含まれています。今後はFeliCa以外の暗号アプリケーションも徐々にAESに移行して行くのでしょうね。

2011年5月9日月曜日

偽装請負と偽装委任

今回はちょっと固い話です。以前、PM関連(を含む)の仕事をしたときに労働関連の法律について勉強しました。このとき、「委任契約だろうが請負契約だろうが、客先に常駐している作業担当者が顧客から直接指示を受けてはいけない」というものがありました。当時は、単純にそういうモノだと思って深く追求はしませんでしたが、IT Proの記事に分かりやすい説明がありましたので引用して紹介します。

引用元:偽装「請負」の請負には「委任」も含まれる
最初に触れたように,「偽装請負」に「委任」は含まれないのではないか,という疑問はもっともなのですが,結論的には厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」にいう「請負」には「委任(委託)」も含まれます。

業務委任契約で客先に常駐するSEについても,この区分基準に基づいて事業の独立性が求められ,独立性がなければ偽装請負(偽装委任?)であるということになります。従って,この連載の2回目3回目で説明したことは,委任契約という形を取ったとしてもそのまま妥当します。委任契約であっても,偽装請負にならないためには独立性を確保する,あるいは実態に合わせて派遣法上の派遣として扱う等の対応が必要なのです。
つまり、民法では請負契約と委任契約は別々の概念ですが、労働者派遣法や職業安定法上の「請負」には民法の「委任」が含まれると言う事らしいです。つまり、請負契約だろうが委任契約だろうが関係ないということですね。

そこで、疑問に思ったのですが、請負(もしくは委任)作業場所に作業者が1名しかいない場合は、作業者が管理責任者を兼任することができるかどうかという事です。本来ならば、顧客 -> 管理責任者 -> 作業者と言う指示パスが存在するはずですが、作業者が管理責任者を兼任する場合は、「人」という単位に着目すると、顧客 -> 作業者という指示パスが存在する事になり、微妙にグレーゾーンになりそうです。

実際に軽くググって見ると、厚生労働省より「労働者派遣事業と請負により行われる事業との区分に. 関する基準」 37号告示)に関する疑義応答集」(PDFです)というFAQが公開されており、質問4にその答えが出ていました。以下に引用します。
Q:
請負事業主の管理責任者が作業者を兼任する場合、管理責任者が不在になる場合も発生しますが、請負業務として問題がありますか。

A:
請負事業主の管理責任者は、請負事業主に代わって、請負作業場での作業の遂行に関する指示、請負労働者の管理、発注者との注文に関する交渉等の権限 を有しているものですが、仮に作業者を兼任して、通常は作業をしていたとしても、これらの責任も果たせるのであれば、特に問題はありません。
また、管理責任者が休暇等で不在にすることがある場合には、代理の者を選任しておき、管理責任者の代わりに権限を行使できるようにしておけば、特に問題はありません。
ただし、管理責任者が作業者を兼任しているために、当該作業の都合で、事実上は請負労働者の管理等ができないのであれば、管理責任者とはいえず、偽装請負と判断されることになります。
さらに、請負作業場に、作業者が1 人しかいない場合で当該作業者が管理責任者を兼任している場合、実態的には発注者から管理責任者への注文が、発注者から請負労働者への指揮命令となることから、偽装請負と判断されることになります。
ということで、一人で客先に常駐する場合は管理責任者を兼任すると、偽装請負として扱われてしまうことになります。請負契約で客先で仕事をする場合は、最低、2名は必要になるということですね。

実際に現場で働くSE達はあまりこういった教育を受けていないような気がします。もちろん私も受けていませんでした。労働関連の法規は結構難しいですが、指揮命令に関する事はPMだけではなく末端のSEにもリテラシーとして教育しておく必要があると思いました。

2011年4月28日木曜日

プロジェクト炎上、復活、そして10連休へ...

ブログ放置しすぎてすんません。3月は案件が炎上&大震災で完全に疲れ切ってました。4月も反動で低調な感じで、やっと連休前になって落ち着いてきたところです。このゴールデンウィークで遊びまくって気分をリフレッシュしたいところですね。

私は、ここしばらくは公開鍵認証局(CA)のCA鍵更新案件に付きっきりでした。CA鍵の更新はどんなCA製品でも大して難しくはありませんが、下手にCA鍵を更新を実行してしまうと、証明書の利用者が証明書を検証できなくなったりして、たいへんなことになってしまいます。今回はユーザーが数万単位と多く、ミスがユーザーの業務継続性に直結するので、より精度の高い仕事が求められていました。

そんな理由もあって、今回は模擬環境を使って更新手順を作成し、十分に検証してから本番で作業をしましたが、既存のドキュメントをベースにした検証用の環境と実際に稼働している本番環境に差が生じてしまい、本番の作業時に様々なトラブルが発生してしまいました。詳細は書く事はでいませんが、初期構築時のドキュメントの記述ミスが数年後になって発覚したことになります。

CAは通常のシステムに比べて運用期間が長くなる傾向があります。特にCA鍵更新等のオペレーションは数年に1度しか行ないません。このため、今回のように初期構築時の不手際が実際に表面化するのが、数年後になるというはありがちなパターンです。初期導入時のドキュメントの作成や、その後のドキュメントのメンテナンスは往々にして軽視しがちではありますが、CAのように長期に渡って運用するシステムについては、多少コストがかかったとしてもしっかりと行なっておく必要があると思います。

また、初期構築時にCA鍵更新や危殆化への対応などの、運用中に発生するイベントを見越してシステムの設計/構築を行なう必要もあると思います。事前に設計しろって言われてもPKIなんぞよくわからん!って人は、RFC 3647が参考になると思います。RFC 3647は証明書ポリシー/認証局運用既定 (CP/CPS) の雛形を提供しています。CP/CPSはCAが発行する証明書の種類や運用方針を記述する文書です。この文書はパブリックなCA(GPKIやSSL証明書販売ベンダーなど)は、インターネットで公開するのが普通です。例えば、SSL証明書の販売で有名なベリサインのCP/CPSはこちらで公開されています。

社内だけで使用するプライベートなCAならば、厳密なCP/CPSの作成は必要ないとは思いますが、CAの設計の際に何を考慮するかわからない場合には、参考になると思います。

2010年12月28日火曜日

2010年のまとめのまとめ

もうすぐ正月だ。来年を気持ちよく迎えるために、今年一年をさらっと振り返ってみますかね。
新バイクの導入
まずは、プライベートから。今年1年の一番のイベントは、新バイクの入手だな。これのせいでライフスタイルが思いっきり変化した。シングルスピードいいけど、やっぱマルチはいいね。

バイクは8月に納品だった。その後、12月末までに8回くらいは山に行った。9〜10月中までは資格の受験対策(ちなみに、合格した)のせいで乗れなかったので、4ヶ月で8回くらいか。駄目だね。全然乗り足りないね。自転車成分が足りなくて脚気になりそう...

反省点は怪我。切り傷と打ち身は数知れず・・・
  • 脛を強打してアザで足が真っ青になる
  • 股間を強打して顔が真っ青になる
  • 前転して頭部を打ってヘルメットが凹む
  • 谷にバイクを落としそうになって自分が落ちて切り傷
  • 日焼けしすぎて皮膚科に行く
あと、前半は機材の故障も多かったな。ということで、来年は少し大人しく乗ります。でもって乗る回数を増やします。


それ以外は?
次に仕事面。前半はCA(公開鍵認証局)の移行作業だった。はじめてRSA製品 + nCipherのHSMの構成を使ったけど、自分でも満足する品質の仕事ができたと思う。慣れない営業仕事もやったから、そっちの方で精神的な負担が大きかったけど、技術面では問題はなかった。自分の適性を実感できた前半でした。

後半も同じような認証局(AD DSとかAD CSとかnCipher HSMとか)の移行作業だったけど、こちらはトラブル続きでした。上司との連携が最悪で思うように仕事が進まなく、「コレが噂の『ピーターの法則』ってやつか!はじめて見たぜ。」とか思ってました。こういう典型的な苦労も自分が人を使う立場になったときに役に立つんだろうと思うと微笑ましい限り。

ということで、来年は仕事のストレスを許容できる範囲で適当に頑張ります。もちろん溜まったストレスは山に捨ててきます。捨てる量がクソ多いので山に行く回数も自然と増えますが、捨てられる分だけマシです。でも捨てられなくなったらどうすっかなぁ。山に籠るか。


2010年、他にもいろいろあったけど、
本当は暗号2010年問題でモメた話とか、i386アセンブラでプチOSを作る話とか、女性に間違われてナンパされた話とかもあるんだけど、たぶん年内の更新は(面倒なので)コレでおしまい。皆様、よいお年を。

2010年9月1日水曜日

RSA Confarence 2010に行きたい!(たぶん無理)

今年も、RSA Confarenceの次期になった。昨年はNETWORK INTEROPと同時開催だったため、会場の隅の方でひっそりとやっていて、RSA社(とPKI業界)の将来に不安を抱いたもんだが、今年はグランドプリンスホテル赤坂で開催するそうな。

どうせ行けないけど、気になるセッションは...
  • CR-001  ブロック暗号・軽量暗号の最新動向
  • CR-002  量子暗号の現状と展望~ セキュアフォトニックネットワークの実現に向けて ~
  • WH-004  高信頼・高安全ソフトウェアのための数理的検証手法:最新の研究と応用の現状
  • CR-003  ハッシュ関数の現状と今後の動向
  • CR-004  クラウド時代の新しい暗号技術~ 関数型暗号 ~
  • CR-005  素因数分解実装実験の最新状況報告

実は、暗号よりも「WH-004 高信頼・高安全ソフトウェアのための数理的検証手法」のセッションに興味がある。私は学生のころ(ずいぶん前だが...)、Fomal Velification Methodのうち、並行モデルのモデルチェックの研究をしていた。当時は論理回路のチェックがCADに実装されたころで、ソフトウェアのチェックは組み込み用途などの非常に限定された分野にしか適用できず、しかも大して役に立たなかったのだ。

並行モデルにおける組み合わせ状態の爆発的な増加の問題が解決されたのか、ブレイクスルーが起こって全数探索以外の動向が出てきたのか。そこら辺が気になるところ。

まぁ、今のスケジュールでは参加できないだろうがね... USTREAMで中継してくれないかなあ。5000円で全セッションが見れるとかだと、すごい助かるんだけど。