iOSの4.3.5で修正された脆弱性がちょっとおもしろい件（CVE-2011-0228）

AppleがiOSのセキュリティアップデートを公開しましたが、PKI的にちょっと面白げな内容でした。パブリックな信頼された認証局から発行されたSSL証明書の私有鍵を使って、別の任意のフィールドを含むSSL証明書を発行すると、その証明書が有効な（Validな）として判定されてしまうそうです。

例として、VerisignからSSL証明書を1通購入するものとします。この証明書は、iPhoneがデフォルトで信頼する認証局から発行されているため、ウェブサーバーにインストールすれば正しいSSL証明書として認識されます。

次に、このSSL証明書を発行する際に生成した私有鍵を使って詐称用の証明書に署名します。このときに、詐称用の証明書には任意のSubject DNやSubjectAltName:DNS等を指定できます。例えば、www.microsoft.comで使用するSSL証明書も発行できます。ここまでは、別に難しいことではなく、OpenSSLを使えば誰でもできてしまいますし、特に不正な行動ではありません。

問題はiPhoneで詐称用の証明書の検証する際に発生します。本来ならば、信頼された認証局（上記ではVerisign）から発行されたSSL証明書のBasicConstraintsフィールドのSubject TypeにはEnd Entityが指定されているはずなので、このSSL証明書の私有鍵で署名した証明書のパス検証を行うと、詐称用の証明書は無効な（invalidな）証明書として取り扱われなくてはなりません。

今回の問題は、詐称用の証明書のパス検証の際に、SSL証明書（上記ではVerisignから発行されたも）のBasicConstrainsフィールドの値を正しく確認しないために、詐称用のSSL証明書が有効な認証局から発行されたとして扱われてしまいます。つまり、第三者が勝手に発行したSSL証明書が有効な証明書として判定されてしまうのです。

これは結構大きな穴だと思います。7/15にiOS 4.3.4が出て、すぐに今回のアップデートが出たことを考えると、Appleもこの問題の危険性を認識しているのでしょうね。

PKI day 2011は9月に開催するんだそうな

ここ数年はPKI Dayは今頃の時期に開催することが多かったのですが、今年は9月26日（月）に開催するそうです。開催場所も変わり、トスラブ山王（山王健保会館）になるそうです。

トスラブ山王は会社の健康診断でお世話になったりしています。建物の感じからすると、会場はあまり広くはなさそうな感じなので、参加人数が制限されてしまうかもしれませんね。

オフィスで熱中症になった件

先日、会社で節電のために冷房を入れないで頑張っていたら熱中症になりました。症状としては以下のような感じでした。

• 頭が痛い。
• 強烈な睡魔に襲われた感じがして頭が働かない
• 突然意識が無くなる
  
• 顔が赤くなる

過去にも熱中症になったことは何度かあり、そのときの症状に酷似していたので、すぐに水を飲んで冷房を入れました。しばらくすると動けるようになったので、その日は代休を使って午後から帰りました。正直、意識が飛んだのにはビビりました。

何でこんなことになったのかというと、節電の為に空調の設定温度を高め（29度）にしていたことと、私の席の空気の対流が悪かったたこと、そして、熱源が多いことです。私の席は胸ぐらいの高さのパーティションに囲まれていて、PCが3台（タワーが2台、ノートが1台）と液晶モニターが3台（マルチモニター構成）稼働しています。空調の風も来ないし、発熱も十分です。

節電も重要かもしれませんが、健康を削ってまでやる必要は無いと思います。節電もほどほどにするのがよいのでしょうね。

ソニーが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に移行して行くのでしょうね。

偽装請負と偽装委任

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

引用元：偽装「請負」の請負には「委任」も含まれる

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

業務委任契約で客先に常駐するSEについても，この区分基準に基づいて事業の独立性が求められ，独立性がなければ偽装請負（偽装委任？）であるということになります。従って，この連載の2回目，3回目で説明したことは，委任契約という形を取ったとしてもそのまま妥当します。委任契約であっても，偽装請負にならないためには独立性を確保する，あるいは実態に合わせて派遣法上の派遣として扱う等の対応が必要なのです。

つまり、民法では請負契約と委任契約は別々の概念ですが、労働者派遣法や職業安定法上の「請負」には民法の「委任」が含まれると言う事らしいです。つまり、請負契約だろうが委任契約だろうが関係ないということですね。

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

実際に軽くググって見ると、厚生労働省より「労働者派遣事業と請負により行われる事業との区分に. 関する基準」 37号告示)に関する疑義応答集」（PDFです）というFAQが公開されており、質問4にその答えが出ていました。以下に引用します。

Q:
請負事業主の管理責任者が作業者を兼任する場合、管理責任者が不在になる場合も発生しますが、請負業務として問題がありますか。

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

ということで、一人で客先に常駐する場合は管理責任者を兼任すると、偽装請負として扱われてしまうことになります。請負契約で客先で仕事をする場合は、最低、2名は必要になるということですね。

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