セキュリティやプライバシーはプログラマの仕事(責任)ではなく開発系のデフォルト機能になるべき

368912557_2fc44d3709_b

【抄訳】
ビッグデータやクラウド、それにますます増えつつある複数のサービス間の相互接続の時代に、セキュリティを確立しプライバシーを保護するためには、ソフトウェアの開発のされ方に構造的な変化が導入されることが必要だ。

MITで博士号を取った研究者(MIT研究助手)Jean YangLinkedIn)は、そう考えている。彼女が自作したプログラミング言語Jeevesは、その主張を実現するために、正しいプライバシーポリシーを正しく強制するという開発負荷を言語自身が担い、プログラマの肩の荷を軽くしている。

“言語など開発基盤の構造がプライバシー/セキュリティの強制機能を持っていれば、プログラマがいちいちチェックやフィルタを書いたり、書き忘れたり、書き方が正しくなかった、などなどの負担と責任がなくなる。プログラマがやることは、最初の、正しいポリシー設定だけになる。これにより、プログラマがミスを犯したり犯さなかったりといった、表層的な問題が解消する”、と彼女は語る。

今月末にラスベガスで行われるカンファレンスPrivacy.Security.Risk.で講演をするYangはこう語る: “学部のころは毎年、こればかり考えていた。人びとはプログラムが正しくないことを気にするけど、プログラマは別に、正しくないプログラムを書こうと思って書いてはいない。だから問題をプログラマに転嫁するのは、正しい方向性ではない”。

Yangも認めるように、最近ではプログラマの瑕疵というより、レガシーコードが抱えるソフトウェアの古い設計に、プライバシーやセキュリティの問題の根因がある、という見方に変わりつつある。

2013年にはNSAの内部通告者Edward Snowdenが政府の諜報機関による監視行為を暴露し、ネット上のプライバシーに関する関心が一気に盛り上がった。Snowdenの暴露により、多くの消費者向けサービスがエンドツーエンドの暗号化を採用するのようになった。そういう消費者サービスも監視の対象になっていた、と分かってからは、そういう商用サービスにおけるユーザ保護が政治の課題にもなってきた。

しかしそれでも今だに、データの盗難は毎週のようにニュースになる。人も企業もアプリケーションも、ネットの上ではますます相互接続性を増してくるが、今のソフトウェアとシステムはそんな時代に合っていないのではないか、という印象がいよいよ鮮明になる。あらゆる面でもっと良い方法を考えなければならないが、Yangの主張では、それには、プログラムの作り方をその構造のレベルで再考する、ということが含まれる。

“今のプログラミングのやり方は、1970年代のやり方から変わっていない。そのころも今も、ソフトウェアは小さなレシピの集合、小さな手続き/ 手順の集合と見なされる。その一つ一つは10〜20行ぐらいだろう。そんなものを大量に使って、弾道の計算など重要なコンピューティングをやっていた。当時はまだ、機密データの保護、という問題はなかった。個々のプログラムはとても小さく、また機密データを扱わなかった。それが1970年代だ”、と彼女は語る。

…お互いについて知る機会のない複数のプログラムが、同じ物理マシンを共有している。そこにはきわめて興味深い、…おそらく恐ろしい…、プライバシーとセキュリティの問題が暗黙裡にある。

“今では、プログラムは巨大だ。ソフトウェアの大きなエコシステムが、いくつもある。プログラムは簡単に、数百万行に肥大する。そのコードのサイズは、70年代にはコンピュータのメモリに収まらなかったほどのサイズだ。つまり書いたプログラムが大きいだけでなく、実動コードも大きい。今や、大量の人間がプログラミングに携わっている。それまでは、一つのプロジェクトを担当するのはひとにぎりのプログラマで、プロジェクトの全貌が彼らの頭の中に十分収まる。そのプロジェクトをめぐるお互いの会話も容易だ。しかし今では、クラウドや仮想マシンを使って、それらの上にコードを置く。お互いについて知る機会のない複数のプログラムが、同じ物理マシンを共有している。そこにはきわめて興味深い、…おそらく恐ろしい…、プライバシーとセキュリティの問題が暗黙裡にある”。

Yangの主張では、さまざまな特色の豊富なデータを大量に集めているFacebookのようなデータリポジトリは、プライバシーにとって、まるで火薬庫のように危険で恐ろしい。Facebookやそのユーザが、ユーザの情報を今後どのように切り刻むのか、それがまったく不明だから。

たとえば、と彼女は言う、ユーザの情報はFacebookのプロフィールの上に時系列で表示されるだけでなく、いわゆるグラフ検索機能(Graph Search feature)によっていろんな方法で検索される。ユーザは、自分のデータが将来どのように見られ共有されることになるのか、知ることもコントロールすることもできない。

“彼らはあらゆるものを持っている。数百万行のコード、プログラマの大群、そしてコードのさまざまな箇所で、機密データが利用される。しかしプログラマは、あらゆる箇所で、“ここでは一体どんなポリシーを強制されるのか”と、問うことしかできない。答はない。

“Facebookに関して人びとは、‘プライバシーのポリシーに一貫性がない。しかも頻繁に変わる’と不平を言うが、自分の情報をプロフィールの上では保護できても、グラフ検索など、そのほかの間接的な方法で情報が見られることに関しては、打つ手がない”。

Yangによると、今でもプライバシーのポリシーを正しく強制し、問題を緩衝する手段はある。たとえばそれは、ライブラリ関数の呼び出しにポリシーを埋め込むのだ。でもそうなるとプログラマは、どういう場合にはどの関数を呼び出す、ということをおぼえて正しく実行しなければならない。プライバシー保護がプログラマの負担・責任になる、という問題は変わらない。

クラウドの時代に機密データを正しく保護するためには、大きな構造的ソリューションが絶対的に必要、とYangは信じているが、ただし、そういうソリューションの採用やそれらへの移行が、プログラマにとって大きな負担になるようでは、どんなに良いソリューションでも正しく普及しない、と彼女は言う。

もっと、‘それとなく’的なソリューションが必要、と彼女は言う。つまりプログラマは従来どおりにコードを書いているが、そのコードの“ボンネットの下”では、ちゃあんとプライバシーとセキュリティの強制が行われている、そんなソリューションだ。例えば暗号化が必要な場面では、プログラマが暗号化をとくに気にしなくても(暗号化のためのコードを書かなくても)データの暗号化が行われる。また、ある箇所ではシステムを保護的な手続きで保護して“まずいことの発生を防ぐ”。最初から、データの健康と安全のための措置が、言語やライブラリに焼きこまれている。…。

“こういう、一見何も変わっていないけどシステム全体に浸透しているソリューション、それで行くべきだ”、と彼女は付言する。

この夏、YangとPhDの同級生Frank WangはMITで、Cybersecurity Factoryと名づけたアクセラレータのパイロット事業を開始した。目的は、Yangらのような学生起業家がセキュリティに関する深い技術的ソリューションを身につけて、上述の構造的問題に取り組んでいくことだ。このパイロット事業はHighland Capital Partnersが出資し、最初の二つのチーム、AikicryptとOblivilockには、どちらも複数のPhDが参加している。来年はこの事業を拡大して、もっと広い範囲から、計五つぐらいのチームを育てたい、という。

またこのアクセラレータでは、アイデアの技術的実装以外に、セキュリティ事前埋め込みタイプの開発系の、普及活動(対投資家、対デベロッパ、対企業、など)も起業家の事業領域とされる。

【中略】

Yangによると、Y CombinatorのSam Altmanも最近は、セキュリティの分野に注目している。たとえばこの夏のツイートで彼は、次の二年間でセキュリティ関連のスタートアップを“数ダース”育てたい、と言っている。システムやデータの保護とプライバシー保護は、Yangたち学究ばかりでなく、投資家の投資ターゲットとしても着目され始めているのだ。

【後略】

 

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

合衆国国土安全保障省が図書館のTORノードを閉鎖、悪用の危険性に配慮

af-library

国土安全保障省(Department Of Homeland Security, DHS)にとっては、終わり良ければすべて良しだから、今日は同省とニューハンプシャー州レバノン市の警察が同市の公共図書館に、テロなどの脅威を防ぐためにTORのノードを閉鎖するよう求めた。

この図書館は合衆国では初めての、セキュアなTORの末端ノードを設けた図書館だった。TORを経由するとWeb閲覧の匿名性が維持され、そのサイトを見ている人の本人性がばれない。そこでDHSと警察は、図書館のローンチ直後にその職員たちにアプローチした。このレバノン市の公立図書館はLibrary Freedom Project(図書館の自由プロジェクト)のメンバーで、このプロジェクトは多くの図書館にTOR末端ノードを置こうとしている。図書館の訪問者の匿名性が維持されると、個人が悪質な国家権力からスパイされたりするおそれがなくなる、というのだ。Viceはこう書いている:

警察や市から、TORは犯罪者が悪用することもある、という説明を受けた図書館は、LFPプロジェクトを脱会した。“しばらく休止しますが、こういう問題が早くなくなることを期待します”、と館長は語った。彼によると、9月15日に行われる評議員会議にサービスの復旧を諮る、という。

DHSのスポークスパーソンShawn Neudauerはこう述べる: “Torの利用そのものは不法ではなく、その利用には妥当な目的もある。しかしながらTorが提供する保護は、犯罪を行う企業や個人を魅(ひ)きつけることもあり、われわれはそういう、匿名化技術を悪用する人たちを追い続けることになる”。

この論理で言えば当然、車も銃もレンガも、その悪用の危険性ゆえに、非合法化されなければならない。次は、何が槍玉に上がるだろうか。

出典: Digital Reader

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Appleが‘Hey Siri’とLive Photoのプライバシー懸念に答える…Googleと対照的な姿勢

screen-shot-2015-09-11-at-4-28-16-pm

Appleは以前から、セキュリティやプライバシーに関する自社の考えや方針を雄弁に語ってきたが、最近ではそれを営業のツールとして利用する傾向もある。それは、個人情報を外に漏らしたくなければAppleのハードウェアを買え、という単純なメッセージだ。

しかし最近ではAppleのハードウェアの基本機能の中に、個人情報を必要とするものもあるから、ユーザの懸念も増している。たとえば‘Hey Siri’機能は、スマートフォンの電源が入っていなくても勝手に動いている。この、ユーザのやることにいつでも聞き耳を立てている状態は、そのデータの扱われ方に関する疑問を喚起する。Live Photosも、新しい気がかりだ。写真に勝手に、動きと音声が付くのだから。

これらの新しい機能は、Appleのプライバシーの取り扱いに関する疑問に導く。その一部については本誌TechCrunchのNatasha Lomasが今朝(米国時間9/11)の記事に書いている。そしてAppleは、本誌が提出したQ&Aにも答えてくれた。

その情報と、今週あちこちからかき集めた知識を合わせると、Appleの言わんとするところが、よりはっきり分かる。

Live Photos

Live Photosはいわば、iPhoneの新しい画像フォーマットで、通常はふつうの写真に見えるが、それをプッシュすると音声付きの超短編のビデオが再生される(スチルの撮影前の1.5秒+撮影後の1.5秒)。

Live Photosの取り扱われ方は従来のiPhoneの写真とまったく同じで、iCloudに送られるときとiCloud上では暗号化される。

Live Photosはユーザがスチルを撮影する「前」にも動画を記録するから、ユーザがカメラを開いて、しかも画面上部にLiveアイコン(オレンジ色の円)があれば、映像が絶えずバッファに記録されている。Appleによると、この1.5秒の記録はカメラがonのときだけ行われるが、ユーザが実際に写真を撮るまでは、それらの情報は恒久的には保存されない。

Appleの説明では、“Live Photoモードではカメラは記録を行っているが、ユーザがカメラのボタンを実際に押すまでの1.5秒映像をデバイスは保存しない。事前に記録された映像はユーザのデバイスに保存されず、またどこかへ送られることもない”、となっている。〔デバイス上に恒久的に保存されるのは、撮影直前+直後の各1.5秒のみ、ということ。〕

なお、Liveボタンをタップしたときは、スチル撮影後の1.5秒も記録される。

本誌が集めた情報によると、Live Photosは1枚の12メガピクセルの画像に、.movのような動画ファイルを合わせたものだ。iOSはそれらの表示を一緒に行うが、実体としては別々だ。写真を誰か・どこかに送るときは、スチル画像だけを送るという指定ができる。相手がiOS 9を使っていれば、もちろん、動画と一緒にLive Photoとして送れる。その場合の暗号化ファイルの伝送量は、その画像の状態によってさまざまだが、だいたい、12メガピクセルの画像二枚ぶんだそうだ。

Appleは曰く、“弊社はLive Photosのプライバシーとセキュリティを、従来のPhotosやVideosと同様に扱う。それらは、ユーザが意図的にシェアしたりiCloudを利用したりしないかぎり、いかなる場合でも、デバイスを去ることはない”。

Live Photos機能はデフォルトだが、アイコンをタップしてoffにできる。

Hey Siri

次は、‘Hey Siri’機能をonにしていたらプライバシー保護はどうなるか? Live Photosよりもこっちが気になるユーザもいるだろう。Siriは、あなたがその特定のフレーズを言うのを待ち受けているわけだから、終始ユーザに聞き耳を立てていることになり、もしかしてすべての発話が、記録されているのではないか?

Hey Siriはオプション機能なのでiOS 9のセットアップのときにyesと答えれば有効になる。そのまま無視ならnoの意味だ。しかし有効になっていても、録音という行為はいっさい行われない。

Appleは曰く、“この機能がトリガされる前にユーザの発話を記録したり、その情報をAppleに送ることは、いかなる場合にもない”。

録音や送信はしないけれど、Siriはマイクロフォンから拾う音をたえず、ユーザがセットアップときに吹き込んだSiri起動命令と比較している。したがって、語句だけでなく声の質もユーザ本人でなければSiriは起動しない。他人があなたのSiriを起動してしまう心配はない。

だからデバイス上に記録されるのはユーザが最初に吹き込んだ命令だけで、ほかはいっさい、記録〜録音されない。比較もデバイス上で行われるから、発話がどっかのサーバなどに送られることもない。

“Siriが聴取しているオーディオは絶えずフレッシュに上書きされており、ユーザがSiriを起動したときのレスポンスタイムの短縮を可能にしている”、とAppleは述べている。重要なのは、比較がデバイス上でローカルに行われることと、次々と入ってくるオーディオは記録(録音)されずに数秒単位で上書き消去されること、したがって今後の取り出しや利用が不可能なことだ。

しかしSiriがいったん起動したら、Siriに対するその後のコマンドはAppleのサーバへ送られるが、その場合はユーザIDとして一時的な乱数が使われる。本物のApple IDや、そのほかの個人情報(氏名など)は送られない。ただしAppleによる個人情報の利用は、今後のサービスの改善のために、ユーザが質問に答えて‘認める’ことはありえる(この問題はSiriとは無関係)。Siriの場合は、Siriサーバは今お相手しているユーザが誰であるかを知らないし、知る必要もない。

Appleは曰く、“ユーザがSiriをoffにしたら、ユーザのSiri IDに結びついているユーザデータをAppleは削除する。その後またonにしたら、学習過程が最初からすべてやり直しになる”。

Appleとしては、もっと便利で高度な個人化機能をユーザに提供するためにはユーザの個人情報が必要だし、しかしそれと同時に、ユーザのプライバシーは絶対に守らなければならない。その両極端のあいだで、適切なバランスを取ることは、きわめて難しい。Siriの場合は、そのユーザIDをユーザの本物のApple IDと無関係にし、しかも一時的な利用だけにすることで、そのバランスを保とうとしている。

AppleのSiriサーバがユーザの個人情報を入手できたら、Siriはもっと便利になるだろうか? もちろん、なるだろう。Appleのデータサイエンティストたちは、モアベターなサービスをモア快速に提供するために、今の何十倍ものデータを処理しなければならない。そんなときでも、データは匿名化されるから無害だ、と主張はできる。Googleは、Google Nowサービスの改良と、データを広告のターゲティングに利用するために、まさにそれをしている。

しかしAppleは、ユーザのデバイス上のデータをなるべくデバイスの外へ出さないことと、Appleが持っているユーザデータをAppleの外(パートナーなど)へは出さないことに、あくまでもこだわる。Hey SiriやLive Photosのような機能でも、そのきわめて保守的な路線を守らざるを得ないのだ。

そして同社は、クラウドサービスでより高度な機能を提供しようとするたびに、このような質問に答えざるを得ないのだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Ashley Madisonのアカウント盗難事件が明かす‘愚かなパスワードは不滅です’

screen-shot-2015-08-19-at-1-10-47-pm

人気の不倫サイト(ただし女性の多くはボットだという説もある)Ashley Madisonの最近のハッキング事件は、数百万のアカウント情報が盗まれるという大規模な被害だったが、われわれに再び、あのおなじみの苦(にが)い良薬を服(の)ませてくれた。それは、パスワードは必ず暗号化されるけれども、暗号は愚かしいパスワードの愚かしさを救ってはくれない、という事実だ。

Ashley Madisonは、そのビジネスの実態が世間のひんしゅくを買ったが、ユーザのパスワードは確実に暗号化していたようだ。しかしbcryptでハッシュしたパスワードであっても、元のパスワードがたとえば、123456のように愚かなパスワードなら、簡単に見破られてしまう。

そして、どういう結果になるのか…

セキュリティ企業のAvastは、Ashley Madisonのアカウントデータベース(そこにはbcryptでハッシュされた3600万件のパスワードがある)から最初の100万件を取り出し、それらをパスワード解読ユーティリティhashcatでスキャンした。その結果25393件のユニークなハッシュの解読に成功し、そこに1064件のユニークなパスワードを見つけた。

ここで‘ユニーク’というのは、ものすごく複雑で解読困難、という意味ではなく、‘これまでに解読したものの中にはそれと同じものがない’、という意味だ。25393-1064=24329件のパスワードには、同じものが複数あったのだ。

同社は解読作業のために二つのよく知られているパスワードリストを使った。ひとつは2008年までのThe Top 500 Worst Passwords of All Time(もっとも多いパスワードのトップ500)、もうひとつは、2009年のRockYouのハックで流出した1400万件のパスワードだ。

これらのデータを利用して同社は、Ashley Madisonのパスワードのもっとも多いトップ20を解読した:

  1. 123456
  2. password
  3. 12345
  4. 12345678
  5. qwerty
  6. pussy
  7. secret
  8. dragon
  9. welcome
  10. ginger
  11. sparky
  12. helpme
  13. blowjob
  14. nicole
  15. justin
  16. camaro
  17. johnson
  18. yamaha
  19. midnight
  20. chris

結果は意外でもないが、でもなぜ、nicoleがそんなに多いのだろう?

Ashley Madisonの営業開始は2001年だから、最初の100万のユーザのアカウント情報といえば、ごく初期のユーザかもしれない。

だとするとそれを、最後の(最新の)100万と比べると、おもしろい結果が得られるだろう。そのほぼ15年のあいだに、パスワードの作り方は進歩し、賢くなっただろうか? Avastは、パスワードのデータベースは時系列でソートされていたと‘想定している’と言っているから、実態は不明だ。

でも、年月とは関係なく、一つだけ明らかなのは、人間はとりあえず、自分にとって覚えやすいパスワードを作ろうとすること。人間の脳はデータの貯蔵庫としてあまり高性能ではないから、どうしても、愚かなパスワードが増えてしまうのだ。この状況を修復するためには、新しいユーザ認証技術の登場、または、もっと覚えやすくて使いやすいパスワード技術の登場、どちらかが必要だ。〔関連記事(未訳)。〕

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Wikipediaが、企業等から報酬を得て宣伝的記事を書いていた、数百名の悪質エディタのアカウントを停止

wikipedia-down

Wikipediaのコンテンツはボランティアが書いているが、ときには、それが仇(あだ)となることがある。今朝(米国時間9/1)同団体は、Wikipediaの英語バージョンのボランティアエディタ381名のユーザアカウントを停止した、と発表した。彼らの容疑は、“特定のグループや企業等に有利な記述を報酬をもらって書いていたこと”だ。たとえば彼らは、この、ユーザが自由にエディットできる百科事典に宣伝記事を書き、そのことで報酬を得ていたことを、隠していた。

この件に関するエディタコミュニティのディスカッションによると、彼らいわゆる‘靴下人形(sockpuppet)’たちは、かなり前から跋扈していた。怪しげな行為に対する調査は7月に始まり、4月から8月までのエディットを調べた。ちなみにこの調査活動のことを、最初に見つかった靴下人形のアカウントにちなみ、”Orangemoody”と愛称している。しかしそれらのエディットの内容は、報酬を得るエディットが相当前から行われていることを、示唆していた。

それらの記事は、企業や企業人、アーチスト関連のものが多くて、偏った情報や誤報、出典が明記されていない…あるいは根拠のない…材料、著作権侵犯らしきもの、などがほとんどだ。Wikipediaの上位団体Wikimediaのブログが今朝、そう説明している。

これらの靴下人形たちが独自に作った210の記事も、削除された。しかし210は、‘それらのすべて’ではないようだ。

ディスカッションのページでは、“このリストは完全ではない。時間的制約があったため、調査の網にかからなかった靴下人形記事もまだ相当あると思われる”、と説明されている。

 

このpaid advocacy(報酬を伴う好意記事)と呼ばれる記事やエディットにWikipediaが直面したのは、これが初めてではない。Wikipediaはもちろん、不偏不党で正確で信頼に足るリソースを目指しているが、2013年の10月には、同団体のボランティアたちが、コンサルティング企業Wiki-PRと結びつきのある数百のアカウントをブロックした。そのときWikipediaはその企業に、業務停止を命ずる書簡を送った。同社は、“Googleの検索結果でトップに来るような記事タイトルを作ってあげる”、と宣伝していたのだ。

Wikipediaによると、同社との結びつきのある300のアカウントを停止した。一方Wiki-PRの方は、その仕事に関わっていたのはわずか45名だ、と主張した

今回停止したアカウントは381だから、前回の300よりは多い。また今回の件でおもしろいのは、ここでもやはり、記事のタイトルや主題が問題になっていることだ(後述)。またこれらの新しい靴下人形たちは、報酬をもらって記事の内容を操作したり新しい記事をポストしただけでなく、月額30ドルで、顧客の記事が削除されないように守る、というサービスを提供していた。

“拒否された草稿や、ときには削除された記事から、‘見込み客’を見つけて接近することが、彼ら靴下人形たちの最新の営業テクニックのひとつだった”、とディスカッションページで説明されている。“記事を‘保護する’ことも、彼らの重要な収入源になった。そのために靴下たちは、わざと、ページの削除をリクエストするのだ”。

この悪事に企業がからんでいたのか、その点をWikipediaは明らかにしていないが、しかしその注記によると、靴下たちが行ったエディットはどれもよく似ているので、一定の指揮下にあるグループがやったことに違いない、ということだ。

問題は記事の編集に報酬が伴ったこと自体ではなく、その場合のガイドラインに従っていないことだ。たとえば多くの博物館、美術館、大学などは、職員の企業等との結びつきを事前に情報公開しなければならないし、また顧客のためのページをメンテしているPR企業は、Wikipediaの、報酬を伴うエディティングのガイドラインサインしなければならない。 Wiki-PRのスキャンダルを契機に作られたガイドラインは、企業やそこの人間に関する記述をエディットするときは倫理的に振る舞うべし、と規定している。

またPR企業等は、記事の主題(企業名等)との関わりを情報公開し、変更に関しエディタたちと協働しなければならない。今回アカウントを停止されたグループは、何も情報公開しなかった。それが目下の、より大きな問題だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

ATMカードのデータを盗む“Shimmer”は薄いので検出不可能

shimalone-580x591

悪賢いATMハッカーたちが、今度は”shimmer”と呼ばれるカードデータ読み取りシステムを使い始めた。非常に薄いので、カードスロットに挿入してもユーザは気づかず、外からも見えない。特殊な器具で調べないと、あることが分からない。

メキシコで見つかったが、それが何にデータを送っているのか、それがまだ分からない。この装置が特別なのは、カードのチップ上のデータを読み取ることだ。ハッカーは装置のチップから送信されてきたデータを保存し、偽(にせ)のカードを作ることができる。ただしATMカードのセキュリティはやや複雑だから、偽のカードは、カードを挿入したときのセキュリティチェックが緩いATMでないと使えないはずだ。

詳しい情報はBrian Krebsのサイトにあるが、ATMのカード読み取り機を手でたたいたぐらいでは、このデータ窃盗機を検出することはできない。ピンセットと懐中電灯を、持参すべきかな。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Macを完全なガラクタにしてしまうゼロデイエクスプロイトが発見された

macbook-pro-2013

またまたBlack Hatが喜びそうな話題。新しいゼロデイエクスプロイトが見つかり、われわれが日常的に使っているコンピュータ製品の弱点を、あらためて思い知らされている。今度のはXeno KovahとTrammell HudsonがOS Xに見つけた深刻なゼロデイ脆弱性で、マルウェアの作者はこれを悪用して、Macを完全にフリーズさせることができる。その際、Macを工場出荷時の状態に初期化することもできない。AppleはThe Guardian紙に、今YosemiteとEl Capitanの両方で対策中だ、と語っている。

このゼロデイエクスプロイトはThunderstrike 2と呼ばれ、接続されているThunderboltアクセサリ…Ethernetアダプタや外付けハードディスクなどを利用してMacのファームウェアを攻撃する。そのマルウェアはフィッシングメールや悪質なWebサイトからコードを受け取り、Thunderboltアクセサリを見つけるとそのオプションROMをフラッシュする。

感染したThunderboltアクセサリが接続された状態でMacをリブートすると、OS Xをブートする前にEFIがオプションROMを実行する。このオプションROMは感染しているから悪質なコードを実行してEFIも感染させ、MacのファームウェアがOS Xのブートを拒絶し、Macを何もできない金属片にしてしまう。ファームウェアがやられてしまったら、OS Xの立ち上げも、ファームウェアのアップデートも、悪質なコードの除去も、すべてできない。

このゼロデイ脆弱性の強みは、Thunderboltアクセサリがずっと感染状態であることだ。だからたとえばEthernetアダプタを新しいMacに接続したら、そのMacもリブート時に感染する。インターネット上で拡散するマルウェアほど有害ではないが、会社などでMacを使ってる場合は深刻な被害になることもある。

Stefan Esserが先月見つけたもうひとつのエクスプロイトは、DYLDと呼ばれる。こちらは犯人がroot特権を持ってしまうから、ハードディスクをフォーマットされてしまったり、あるいはお金にかかわる被害が生じたりすることも、ありえる。

Malwarebytesが見つけたDYLDの悪用例は、あるアドウェア作者によるもので、rootパーミッションを取得したらスクリプトを実行して大量のアプリケーションをインストールする…それらは、アドウェアのVSearchやGenieo、ジャンクウェアのMacKeeperなどだ。また、Download Shuttleをインストールせよ、というプロンプトが無限回出るので、Mac App Storeを利用できなくなる。

AppleはEl CapitanのベータではDYLDをフィクスしたが、今のYosemiteはまだだ。このエクスプロイトを悪用するアプリケーションをマルウェアのブラックリストに加えたが、それは一時的な安心材料でしかない。OS X YosemiteもOS X El Capitanベータも、いずれはセキュリティパッチが発表されるだろう。でも当面は、何かをダウンロードするとき用心すること、そしてMacをリブートする前には必ず、すべてのThunderboltデバイスを外すことが重要だ。万一に備えて。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Googleが主要キャリア8社をAndroid for Workのパートナーに加える…一挙に採用企業拡大か

android-work

GoogleのAndroid for Workは、企業が社員たちに、Androidフォーンを仕事と個人用の両方で安全に使わせるための企画だ。この事業によって企業のIT部門は仕事用のアプリを管理できるようになり、フォーンの個人利用の部分から隔離される。社員は自分のプライベートなデータを前と同じように自機の上に置けるが、それらがITから見えることはない。

Googleがこのプログラムをローンチしたのは今年の初めで、そのときすでに、Android for Workを市場化するために多くのパートナーを揃えていた。そして今日(米国時間7/30)は、新しいデバイスメーカーとともに、キャリアをパートナーに加えた。

これからAndroid for Workを企業顧客向けにサポートし、市場化することになるキャリアは、AT&TとVerizon、T-Mobile、Sprint、Rogers、Bell Canada、Telus Mobility、そしてKTだ(Verizonは今や、本誌TechCrunchのオーナーである)。

今回新たにパートナーになったデバイスメーカーはSilent Circle、ここはセキュリティとプライバシーを強化したスマートフォンBlackphoneを作っている。Samsungと同社のKNOXプラットホームもパートナーのリストに載っており、これによりAndroid for Workデバイスは政府関係や保健医療など、規制の厳しい業界でも使えることになる。

Screen Shot 2015-07-30 at 6.08.59 AM (1)

Silent Circleの社長でCEOのBill Connerは、今日の声明文の中で、“プライバシーは、どの情報を、どのように共有するかを、自分で決めてコントロールできることだ。Android for Workプログラムに参加できることは喜びであり、これによりSilent Circle製品のプライバシーとセキュリティの能力は一層高まることになる。またそれと同時に、AfWの隔離機能によりユーザは、プライバシーとセキュリティを確保しながら、より多様なアプリケーションやサービスを利用できるようになる”、と述べている。

Googleによると、今AfWを採用または試用中の企業は1万社以上あり、その中にはWorld Bank(世界銀行)、U.S. Army(合衆国陸軍)、Guardian Life Insurance Companyなども含まれている。1万のうち何社がAfWを実用展開しているかは、明らかでないが、でもこの事業が、多くの企業にとって、BYODという厄介な問題のソリューションになることは、ほぼ確実だ。‘仕事のとき専用の携帯’を持たされずにすむ社員も、大いに助かる。

[PRESS] Android for Work - Press Deck - 25 Feb 15 - Google Slides

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Google Compute Engineの上でデベロッパが自前の暗号鍵を使えるようになる…それが必要な業界など向け

5399162987_5d0402e809_o

今日から(米国時間7/28)は、GoogleのIaaS Compute Engineを使っているデベロッパが、このサービスで自分独自のセキュリティキーを使える。この、暗号の鍵を顧客が供給する方式は、目下、公開ベータ中だが、データのセキュリティに関するコントロールをユーザ側に与えるものだ。

デフォルトではGoogleは、そのサービス上のすべてのデータをAES-256ビットの暗号化キーで暗号化し、(a)キー自身も暗号化され、(b)定期的にローテーションされる。今度の新しい(無料の)機能を使うと、ユーザが自分のキーを持ち込み、データの暗号化状態の管理を、そのぶん、より自由に行えるようになる。たとえば、データをいつ静止状態とみなすか、アクティブとみなすか、といった選択もデベロッパの自由になる。Googleはそのキーを保持しないから、同社の中の何人(なんぴと)たりとも、静止状態のデータにアクセスできない。

GoogleのプロダクトマネージャLeonard Lawが、こう言ってる: “セキュリティはデータ保護のイシューであると同時に、コントロールのイシューでもある。暗号鍵を顧客が供給すること(Customer-Supplied Encryption Keys)によって、Google Compute Engineでデータを暗号化するやり方に関するコントロールを、ユーザに与えることになる”。

Lawはさらに、Googleのサービスはすべての形式のデータをカバーする、と強調している。データのボリュームでも、ブートディスクでも、あるいはSSDでも。

しかし現実には、セキュリティキーを自分で扱うのは面倒、という人も多いだろう。鍵を紛失したら、データを回復できない。Googleによれば、この機能を使うのは主に、金融とか保健医療など規制の厳しい業界の、大きな企業・組織・団体だろう、という。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Androidに最悪の脆弱性発見―ビデオメッセージを受信するだけでデバイスが乗っ取られる

2015-07-28-android

まるで出来の悪い映画のようだ。善玉の主役が悪玉の世界転覆計画を暴こうとしている。善玉は悪玉のスマートフォンをハックする。それがなんと相手のデバイスにメッセージを送るだけでできてしまう。アプリをダンロードさせることもメールを開かせることも必要ない。相手の電話番号さえ知っていればいい。それだけで、ジャーン! 相手の携帯の乗っ取り完了だ。

研究者によれば、おそろしいことに、これは映画ではなくて現実なのだという。大部分のAndroidデバイスがこの脆弱性を抱えている。

要点はこうだ。

  • Zimperium Mobile Labsのプラットフォーム侵入対策担当副社長、Joshua Drakeによれば、「95%のAndroidデバイスにこの脆弱性が存在する」という。
  • ハッカーは悪意あるコードを仕込んだビデオ・メッセージを送信する。このメッセージはAndroidのサンドボックスを迂回し、リモート・コードを実行する。この時点で攻撃者はストレージ、カメラ、マイクなどデバイスのほぼ完全なコントロールを得る。
  • このハッキングはStagefright攻撃と名付けられた。 StagefrightというのはAndroidがビデオを処理するメディア・ライブラリーの名前で、悪意あるコードはこの部分で実行される。
  • 多くのAndroidのバージョンでは、デバイスはユーザーが手動でメッセージを開かなくとも、着信と同時に処理を始める。つまり悪意あるメッセージを受信しただけで乗っ取りの過程が開始されてしまう。
  • 攻撃者は、理論的には、乗っ取りが完了したらメッセージ自体を削除してしまうことが可能だ。するとメッセージを受信したという通知以外には後に何も残らない。ほとんどのユーザーはこうした通知はスワイプして忘れてしまうだろう。
  • このバグはAndroid v2.2 (Froyo)で導入された。ZimperiumではAndroid 5.1.1 (Lollipop)までのすべてのバージョンでこの攻撃の有効性を確認した。その中でもJelly Bean (4.1)より古いデバイスがもっとも脆弱性が高いという。

良いニュースは、このバグはオンライン・アップデートでパッチ可能なことで、Googleはすでにそのパッチを配布ずみだ。

しかし悪いニュースは、このパッチの配布はそれぞれのデバイスのメーカーを経由しなければならないという点だ。つまり時間がかかる。Froyo、Gingerbread、Ice Cream Sandwich搭載のデバイスには長い間アップデートされていないものがある(11%近くのAndroid携帯がそうだという)。こうしたデバイスは最後までパッチを受け取れないかもしれない。

この攻撃に対してAndroidユーザーが身を守る方法があるかどうかは不明だ。もし何らかの方法があることが分かればすぐに紹介する。

われわれの問い合わせに対してGoogleの広報担当者は以下のようにコメントした。

「われわれはこの問題に関するJoshua Drakeの貢献に感謝している。Androidユーザーのセキュリティはわれわれにとってももっとも優先される課題だ。Googleはすでにこの脆弱性を解消するパッチをメーカーに提供ずみだ。このパッチはあらゆるAndroidデバイスに適用できる。

[原文へ]

(翻訳:滑川海彦@Facebook Google+

Google、Googleマップ上に過去の訪問地履歴を表示する機能を公開(Googleはなんでも知っている!)

3955197105_21d2a70850_o

FoursquareないしSwarmは、「チェックイン」という行動よりも、よりその「場所そのもの」を扱う方向へと進んでいるようにみえる。その流れに乗ってか、Googleも「Your Timeline」という機能をリリースした。これまでに出かけたことのある場所を表示するものだ。情報を閲覧できるのは自分のみで、これは「ソーシャル」なものではない。

ただし。

この機能には気味の悪さを感じる人もいることだろう。標準でオンになっているオプションをそのままにしておくと、Googleにはこれだけのデータが伝わることになるのだ。現在のところこの機能はAndroid版およびウェブ版のみで提供(順次公開中)されている。Google Photosを使っているのなら、訪問した場所とともにその場所に関連する写真も表示されるようになる。

「Your Timeline」がどのようなものかを示しておこう。

2015-07-15 13_47_42

Google Mapチームの説明を見てみる。

これまでに出かけた場所を簡単に一覧できたらと思ったことはないでしょうか。昨年夏に訪問したミュージアムや、あるいは数カ月前にふと立ち寄ったバーのことを思い出すきっかけになるかもしれません。と、いうわけでGoogle Mapsに新しい機能を追加しました。適用ユーザーを徐々に広げている最中ですが、Google Mapsのメニューに「Your Timeline」というメニューが表示されるようになります。特定の日、1ヶ月ないし1年前に訪問した場所をチェックできるようになります。日常の行動や、あるいは旅行の思い出、あるいはちょっと出かけてみた場所などを手軽にデータとして振り返ることができるようになるわけです。

もちろんGoogleはあくまでも肯定的な表現で説明している。しかしスマートフォンのロックが解除されれば、自分の行動がすべて筒抜けになるということを意味する。いつ、どうやってモーテルに出かけたかなどという情報が「自由に」閲覧されてしまうのだ。そんな秘密がすぐそこに転がっているのなら、つい自分のパートナーのスマートフォンをチェックしたくなるという人も多いのではなかろうか。

「やばい」と思った人はアカウント情報ページにて、機能をオフにしておくことを(老婆心ながら)おすすめする。

Screen Shot 2015-07-21 at 4.53.49 PM

「後ろ暗いところなどない」と思う人はそのままで大丈夫。忘れていた過去を思い出すきっかけとなってくれることだろう。

原文へ

(翻訳:Maeda, H

モバイル時代のパニックボタンWitnessがアプリとして完成、App Storeに登場

witness-app

モバイル時代のパニックボタンとして使えるライブのストリーミングアプリWitnessは、今年のTechCrunch Disrupt NY 2015のハッカソンでデビューし、最後には大賞を獲得した。今やそのアプリがAppleのApp Storeで入手できるようになり、ユーザはあらかじめ指定しておいた複数の緊急時連絡先に自分の現在位置と、音声とビデオを自動送信できる。Twitterの自撮りビデオPeriscopeのプライベートバージョンが、身の危険を感じるような緊急時に友だちや家族に、ヘルプ信号として送られるアプリ、という説明でもよいかもしれない。

これを作ったデベロッパのMarinos Bernitsasは、それまでニューヨークでやっていたアルゴリズム取引の仕事を辞めて、かねてからやりたかったモバイルアプリの制作を始めた。Witnessは最初、夜道を一人で歩いて家に帰るなど、危険な状況で使うアプリとして構想された。

しかしハッカソンのオーディエンスや審査員たちは、警官の暴力行為など、公務員の違法行為を証拠として記録できる可能性に、関心を寄せた。このアプリが披露されたころは、警察が批判されるそんな事件が多かったのだ。

witness1

 

実際に、ティーンたちが警官にやられたテキサス州の事件では、複数の目撃者が警察の行為を自分のモバイルフォーンに記録していた。そのおかげで後日、問題の警察官は訴追された。Witnessアプリは、まさにこれと同じことができるし、しかも現場記録だけでなく、リアルタイムで事件の映像を愛する人たちに送信+録画できる。

ハッカソンのときは機能も単純で、ユーザが事前に緊急時連絡先のリストを自分のスマホに入力しておくと、受信した側では自動的に録画を開始し、ユーザにはテキストメッセージで着信を知らせる。おもしろいのは、Witnessが動いているときは画面が真っ黒で、送信や録画が行われていることを他人に隠せることだ。

  1. 1.png

  2. 2.png

  3. 4.png

  4. 3.png

  5. 2-both.png

  6. 5.png

App Storeで入手できるようになったWitnessアプリは、デフォルトでは真っ黒画面にならないが、事前にそう設定しておくこともできる。作者のBernitsasは、今後はいろんな初期画面を用意してユーザが選べるようにしたい、とも言っている。

今のWitnessはレイアウトもきれいになったし、Witness同士の送受信だけでなく、映像などの情報をメールでも送れるようにした。事前に設定した緊急時連絡先リストだけでなく、メールのアドレス帳との統合もできる。誤操作防止機能も、ついた。一秒間、画面のどこかを押しているとWitnessが起動して、リアルタイムの映像とメッセージをメールなどで送り始める。

受信した側は、Witnessアプリが動いていなくても、テキストメッセージ中のリンクをWebブラウザで見れば、地図上で被害者の動きが分かる。受信側の信号の状態が悪ければ、Witnessはすべてをローカルに保存して、受信側の状態が良くなったときにアップロードする。犯人〜加害者が被害者のスマートフォンを破壊した場合でも、情報は完全にWitnessのサーバ上に残る。そしてもちろん、証拠等として利用できる。

3

Bernitsasはアプリを発表する前に少人数のグループでテストしてみたが、83%が緊急時にこれを使いたいと答え、91%が、これが自分のスマホにあれば安心だ、と答えた。

今のところ収益化計画はなく、アプリも無料で、とにかく世の中で実際にどんな使われ方をするか、それを知りたいのが今のBernitsasの本音だ。

“これまでの、ありとあらゆる仕事と違って、これだけは、最初からビジネスとして考えていない。ぼくにとってこれは、24時間で作れる、友だちや家族のためのクールなユーティリティ、でしかなかった。Disruptで賞を取りたい、という考えすらなかった”、とBernitsasは説明する。

“その後、いろんな人からWitnessが役に立つという話を聞いて、その話にとても感動した。そんな声を聞いたからこそ、できるだけ早くアプリとして完成させてApp Storeに出したい、という気持になった。でも、まだ、改良の余地はたくさんある。Witnessは、今後まだまだ良くなるよ”、と彼は付言した。

このアプリは無料で、iTunesからダウンロードできる。

[原文へ]
(翻訳:iwatani(a.k.a.
hiwa

Flashに第三のゼロデイホール発見、被害者のシステム乗っ取りもありえる凶悪欠陥

xoom-flash-1

TrendMicroがまた、ユーザのデータを危険にさらす、Flashの緊急のゼロデイホールをポストした。政府にハッキングツールを提供し、その情報データベースの全体が最近リークされた、プロフェッショナルなハッカーグループThe Hacking Teamが、このエクスプロイトを利用して、ユーザに気づかれずにコンピュータを攻撃することに成功した。

この新たな脆弱性はCVE-2015-5123と呼ばれ、ほかの二つのゼロデイエクスプロイトに続くものだ。このエクスプロイトは、Adobeによると、“クラッシュを引き起こし、犯人が被害システムのコントロールを奪うこともありえる”。

今では、Flashを完全に亡きものにせよ、との声がある。そうすれば、穴(ホール)掘りが大好きな何百万ものアナグマたちもいなくなる。

まじめなご忠告: Flashを無効にしてください。Windowsではこうやって削除します。OS Xではこうです。Flashを使うというリスクを、冒す価値はまったくありません。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

AdobeがまたまたFlashのゼロデイホールを修復…まだ実害の報告はないが

ht-exploit-580x430

多くの企業にベストプラクティスがあるが、連邦政府や州政府のお役所にハッキングツールを売ってきた“コンピュータセキュリティのエキスパートの集団”Hacking Teamも、その例外ではない。同社の情報データベースにはおもしろいハッキングティップがいろいろ載っていて、その中にはAdobe Flashのまだパッチされてないゼロデイホールへの言及もある。Adobeは目下、その穴を閉じる工事をやっている。

セキュリティ研究家のBrian Krebsが数日前にそのドキュメントを、ハッカーたちがリークしたデータの山の中に見つけた。Hacking Teamが概念実証のためにやってみた攻撃は、WindowsやOS Xのカリキュレーター(電卓)を開く、といういたずらだが、もっと悪質なバージョンもある、とそのドキュメントには書かれている。

Adobeは今日(米国時間7/8)、Security Bulletin CVE-2015-5119をポストして、今その穴を塞ぐ作業をしている、と述べている。

セキュリティ企業のTrend Microは、“現時点ではユーザはこの脆弱性についてそれほど心配する必要はない。実際の犯行はまだ発見されていない。今後は必要に応じて、このポストの内容を更新していく”、と述べている。しかしHacking Teamがこの脆弱性の新たな悪用の方法を発見したかどうか、それがまだ明らかでない。

ひとつだけはっきりしているのは、Flashを無効にした方が良さそうだ、ということ。Krebsは曰く、“疑問の余地なくAdobe Flash Playerは攻撃者の主要なターゲットの一つだ。AdobeがFlash Playerのゼロデイ欠陥を修復する緊急アップデートを発行するのは、この数か月間で今回が7度目だ”。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

WikipediaなどWikimedia FoundationのサイトがデフォルトでHTTPSを採用…政府機関による検閲などを抑止へ

wikipedia-down

【抄訳】
Wikipediaなどの重要なwikiプロジェクトをホストしているWikimedia Foundationが今朝(米国時間6/12)、今後はすべてのサイトのトラフィックをHTTPSにより暗号化する、と発表した。同団体によると、これにより各国の政府などがユーザトラフィックをモニタすることが困難になり、またISPがWikipediaなどの記事を検閲することも難しくなる。

同団体は2013年に、サイトのアカウントを持つログインユーザのトラフィックに関してはHTTPSを実装したが、そのとき、中国やイランなどトラフィックのHTTPS化が難しい国に関しては、ログインユーザに対しても従来どおりのアクセスを認めた。

しかし今日のWikimedia Foundation(WF)の報告では、同団体はHTTP Strict Transport Security(HSTS)を使用して、トラフィックをHTTPS破りから保護する、と言っている。

同団体はネットワークのインフラストラクチャの弱い国でも、レイテンシなどの問題がなるべく起こらぬよう、HTTPSの構成等に細心の配慮を講じているが、しかし事務局長のLila Tretikovが以前インタビューで語ったように、まさにこのインフラの格差という問題こそが、これまで暗号化によるユーザ保護をためらってきた原因だ。したがって実際に起きる影響を、今後も見守っていく必要がある。

今日WFが発表した談話によると、“中国ではここ数週間、中国語WikipediaはHTTPとHTTPSの両方で、多くのユーザにとってアクセス不能になっている。しかし、香港や台湾など一部の、アクセスできているユーザにとっては、HTTPSがセキュリティの向上に資すると思われる。また、中国でも英語版Wikipediaにはアクセスできるので、英語版の利用に関しては、ユーザはHTTPSのセキュリティ効果に浴することができる”、ということだ。

ユーザがトラフィックのHTTPS化をオプトアウトする方法は、2013年のときと違って提供されていないが、そのために政府等がユーザのWikipediaアクセスを妨害することがより困難になるはずだ、とWFは言っている。

また同団体は、ブラウザプラグインHTTPS EverywhereによるHTTPS化を、4年前からサポートしてきたことにも触れている。またユーザが大手の検索エンジンからリダイレクトされてWFのサイトにアクセスした場合も、HTTPSをサポートしていた。

【後略】

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Googleがユーザ個人のプライバシー/セキュリティ総合ダッシュボードを提供…一箇所でチェックや変更が可能

ac_home_us-1

Googleが今朝(米国時間6/1)、ユーザのプライバシーコントロールを改良したことと、Googleのデータ収集をめぐる人びとの懸念に答えるための、新しいWebサイトを立ち上げたことを発表した。後者のサイトではユーザ個人の設定ページMy Accountが最初に現れ、そこでユーザはGoogleのさまざまなサービス…検索、地図、YouTubeなどなど…のプライバシーとセキュリティの設定を、見たり変えたりできる。また、ユーザが訪れたWebページや、アプリケーション上の活動、位置の履歴などの、Googleによる保存を無効にもできる。

“My Account”という名前になっているが、この設定ページはGoogleのアカウントのないユーザでも利用できる。

この新しいサイトでユーザはPrivacy Checkup(プライバシーチェック)やSecurity Checkup(セキュリティチェック)などのプログラムを走らせ、どのデータを公開にするかプライベートにするか、どのデータならGoogleが個人化(パーソナライゼーション)に利用してもよいか、などを指定する。たとえばユーザは、Google+のプロフィールに載ってもよいコンテンツや、Hangoutなどのサービスで他人が電話番号から自分を見つけてもよいか、YouTubeの会員情報をプライベートにするか、などを指定できる。

また、YouTubeの検索履歴や視聴履歴、デバイス情報、音声とオーディオのアクティビティ、位置履歴、ブラウザの履歴なども、Googleがそれらを保存してよいか、いけないかを指定できる。

またprivacy.google.comというサイトでは、Googleがどんなデータを何のために集めているのか、という疑問に答えてくれる。答えの多くは、“Googleのプロダクトを利用するときの体験をよりカスタマイズして、ユーザとの関連性の強い広告をお見せするため”、である。

answers site

Googleがそのサービスに関する情報を一箇所にまとめるのは、これが初めてではない。2009年にはGoogleはGoogle Dashboardを立ち上げ、2012年にはそれをさらに詳細にし、アクセスに関する数値情報も見られる専用のサイトを作った。

もちろんこれまでにも、プライバシーやセキュリティの設定は個々のサービスごとにできたが、今回のMy Accountハブの目的は、一箇所ですべてが見られて設定もできることによって、ユーザの混乱を避け、利便性を向上することだ。案内文も、より親切になった。

このところ大規模なインターネットサイトにおけるユーザデータの利用や保護に関する懸念が、政府の監視行為がばれたことなどにより、高まっている。とりわけGoogleは、検索やメールなどを初めとして、ユーザの日常のネット生活と深く関わっている部分が多いだけに、ユーザの懸念は大きい。

同社は2012年にユーザのプライバシーポリシーを一元化することによって、Googleの多種類のサービスへのアクセスを容易化し、ユーザが今Googleアクセスしていることをより正確に同定できるようにした。ところがこの新方針は多くのデータ保護勢力からの批判を招き、罰金刑の脅しまで頂戴するはめになった。

今回の、プライバシーとセキュリティ専用サイトの立ち上げは、規制当局のそのような懸念に応える意味もある。Googleは、集めている個人情報やその用途についてもっと明確に説明せよ、と迫る勢力もある。そしてそれらは、アプリケーションごとに漫然とやられるのではなく、Googleのプライバシーポリシーとして明記されるべきである、と彼らは主張する。Googleは1月にはイギリスの政府当局と、個人情報の収集に関して契約を交わし、プライバシーポリシーに関するコンテンツを、一般消費者に対しもっとアクセスしやすくする、と約束させられた。

今回の新しいハブは、Googleによるデータの利用のされ方に不安と疑念のあるユーザに、その全体像を一箇所で明らかにするとともに、ユーザがそれらの設定を自由に変更できることを、知らしめることも目的だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

GoogleのVaultプロジェクトは一枚のmicroSDカードに収めたセキュリティ万全のコンピュータ…企業利用を念頭

google-io-2015-atap0076

Project VaultはmicroSDカード大のデバイスにセキュアなコンピュータを収容した製品だ。GoogleのATAPによると、microSDの形を選んだのは、すでに携帯電話上に、高度なセキュリティ機能があるからだ。携帯のSIMカードは、キャリアにとって重要な情報を確実に保護しなければならない。Vaultもそれを志向しているが、守るのはユーザの重要なコンテンツだ。

またmicroSD形式なら、ビデオの再生などにも適した高いデータスループットが得られる。容量が大きいので同一カード上にストレージを併設でき(Vaultは本体上に4GBのストレージがある)、またモジュール性が良いので可搬性にも富む。

Vaultの上ではARMのプロセッサがリアルタイムオペレーティングシステムRTXを動かしている。このOSは、プライバシーとデータのセキュリティがとくに強化されている。NFCチップとアンテナもあるので、ユーザの本人認証も確実だ。また、ハッシュ、署名、バッチによる暗号化(not個別処理)、ハードウェアによる乱数生成など、一連の暗号化サービスを内包している。

  1. google-io-2015-atap0072.jpg

  2. google-io-2015-atap0073.jpg

  3. google-io-2015-atap0075.jpg

  4. google-io-2015-atap0076.jpg

  5. google-io-2015-atap0077.jpg

  6. google-io-2015-atap0078.jpg

  7. google-io-2015-atap0079.jpg

Vaultは、二要素認証を誰もが使いやすい形で提供し、デベロッパはそれを利用するために特別な作業を必要としない。システムはそれを、標準的なファイルシステムが載っているジェネリックなストレージと見なす。

そのファイルシステムには、ファイルが二つだけあり、それぞれ、リード用とライト用だ。どのアプリケーションも、Vaultとコミュニケーションするためには、これらを利用しなければならない。また、ホストのコンピュータや電話機から見るとジェネリックなストレージにすぎないから、AndroidやWindows、OS X、Linuxなど、そのほかのオペレーティングシステムでも使える。

ATAPは今日(米国時間5/29)のGoogle I/OでオープンソースのSDKをリリースしたから、誰もが正規の立ち上げの前にVaultを理解し試用ができる。企業が利用するための正規の製品もすでにあり、それは今Googleの内部で使われている。また将来的には、消費者向けの製品も出す予定だ。

ATAPがI/Oで行ったデモでは、Vaultを使ってチャットの会話のセキュリティを確保する例が示された。Vaultの載ったmicroSDがインストールされると、チャットアプリケーションがファイルが二つだけのファイルシステムへと仮想化されたストレージを開き、リード/ライトを行う。メッセージはVaultがすべて暗号化し、暗号化されたテキストが送信される。受信側の携帯はその会話を解読するが、どちらの側も、ユーザレベルにはキーやアルゴリズムは何もない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

寿命の短い第二鍵によるクラウド認証を提供するScaleFTがシードで$800Kを調達

2015-05-11_1208

Rackspaceの元役員や技術者たちが始めたDevOpsサービスScaleFTが今日(米国時間5/11)、本家Rackspaceからの戦略的投資として80万ドルのシード資金を獲得した、と発表した。この投資ラウンドには、CoreOSのCEO Alex Polviなど、数名のエンジェル投資家も参加した。なお、PolviはRackspaceの出身だ。

前から報じられているように、RackspaceはクラウドサービスとしてAmazon(AWS)やGoogle、Microsoftなどと競合するだけでなく、それらのユーザを顧客とするサービスを提供しようとしている。ScaleFTの協同ファウンダでCEOのJason Luceが言うように、ScaleFTのプロダクトはRackspaceのそういう最近の方向性にもフィットしているのだ。

Luceは今日の声明文の中で、“RackspaceはAWSやGCE、Azureなどのユーザが利用するサービスを積極的に手がけてきたが、ScaleFTはそういうRackspaceのOpsチームが彼らの新しい戦略のために必要とするツールを、より高度化する。Rackspaceが弊社の取り組みを支援するのは、そのためである”、と述べている。

同じく今日ローンチするScaleFTの最初のプロダクトScale Accessは、サーバへのアクセスをより容易に、そしてよりセキュアにする。同社の主張によると、SSHの秘密鍵に基づく認証ソリューションは、面倒であるだけでなく、実はそれほどセキュアではない。“今あるRSAやX.509、SSHなどの技術はあまりにも複雑なので、企業がそれらをもっとも効果的に利用することが難しい”、とLuceは述べている。

それに対してScale Accessは、有効期間が数分と短いキーを使用し、その認証ソリューションはGoogle AppsやSAMLのようなシングルサインオンのソリューションに統合できる。そのためそれは、認証のための第二要素を必要とするツールで利用できる。

つまりSSHをそのまま使えるし、AnsibleなどのIT自動化ツールも従来どおり使える。そしてScaleFTのサービスが、VPNやWebアプリケーションや、そのほかのインフラストラクチャサービスへの証明を発行するのだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Google、パスワードの使い回しを制限するためのChrome拡張機能をオープンソースで提供開始

phishing_caught

Googleが新しいChrome拡張機能をリリースした。Googleサイトで利用しているパスワードを、他のサイトで再利用しないように注意を喚起するためのエクステンションだ。パスワードアラート(Password Alert)という名前で、Chromeウェブストアにて入手することができる。この拡張機能をインストールしておくと、Googleサービスで利用しているパスワードを他サイトで使用しようとすると、警告が表示されるようになる。

GoogleのGoogle Apps for Workチームでセキュリティ部門のディレクターを務めるEran Feigenbaum曰く、Google社内でもこれと似たツールを数年にわたって利用してきているのだそうだ。

主な目的は、フィッシング被害を防ぐことにある。Feigenbaumによれば、Googleの社員ですらGoogleのログインページを偽装するフィッシングサイトに騙されてしまうことがあるのだそうだ。

gyb_pw_alert_blog

但し、このツールが役立つのはフィッシング詐欺に対する場面のみではなさそうだ。多くの利用者がさまざまなサービスで同じパスワードを使いまわしている中(もちろん、TechCrunch読者はそのようなことはしていないはずだが…)、悪意のハッカーは、なんらかの方法でひとつのパスワードを盗み取ればあらゆる情報にアクセスできるような状況にもなっている。

2段階認証も、そうした状況にストップをかけるのには有効な方法だ。GoogleのSecurity Keyを使うのも良い方法だろう。しかし、セキュリティについていろいろと考えている利用者以外にも、パスワードの使い回しをストップさせるという面で、このパスワードアラートも有効に機能するはずだ。

Feigenbaumの話によると、Google for Workではこのツールを使って、利用者のそれぞれにパスワードアラートの機能を提供することもできるのだとのこと。Google for Workのメンバーが、Google for Workのサイト以外で同じパスワードを使えば、アラートが表示されるようになる。

もちろん、パスワードアラートを使うのに、Google Apps for Workを使っている必要はない。多くの人が日常で利用しているであろうGoogleアカウントにて、正しく機能するようになっている(複数のGoogleアカウントを使い分けているような場合は、少々めんどうなことになるようではある)。

このパスワードアラートはオープンソースで提供され、他のブラウザ用のプラグインを開発することも可能となっている。

原文へ

(翻訳:Maeda, H

電話をかけようとすると、画面に当たる耳の形から所有者本人を判定する技術をYahooが開発

ear

あなたの携帯電話では、あなた本人しか入呼に出られない、としたら、すてきじゃないですか。しかもそのために指紋もパスワードもスワイプジェスチャも要らない。そのアプリは、電話をかけようとする人の耳の形をチェックする。指紋センサは使わない。今やどの携帯電話〜スマートフォンにもある、タッチスクリーンを使うだけだ。

それが、このたびYahooの研究所が作ったBodyprintのアイデアだ。

研究員のChristian HolzとSenaka ButhpitiyaとMarius Knaustが作ったBodyprintは、体の各部を各状況にもっとも合ったバイオメトリクス(生体認証)の指標として利用する。電話をかけるという状況では耳を利用するが、そのほかの状況では手のひら、握った手の最初の関節、デバイスを握ったときのエッジまわりの手の形、などなども本人認証に利用できる。

それだけいろんなものを認識できるのなら、スクリーンから指紋を認識した方が早いではないか? しかし今のセンサやスマートフォンのタッチスクリーンの技術では、指紋を正確に識別するほどの精度が得られないのだ。Bodyprintでは、指紋よりももっと大きなものなら、その形を区別できる。

耳や手のひらなどは、自分と似ている人がいるから、このシステムはどこまで正確に見分けてくれるのか? 彼らが書いた研究論文によると、正確度は99.52%、つまり1000回のうち5回しか間違えない、ということだ。

問題は、このアルゴリズムが、ちょっとでも怪しいと拒絶するタイプなので、“偽りの拒絶率”が体の全部位で26.82%と高いこと。耳だけなら7.8%だ(13回に1回は本人が拒絶される)。もしも電話の拒絶が4回に1回もあれば、ちょっと商品化は無理だろう。なお、試験に参加した人数はわずか12名だそうだ。

今は、商用レベルの完成度云々ではなく、コンセプトの初期という段階だ。スマートフォンの指紋判読も長年ひどかったが、最近になってやっと、不満をおぼえない程度の技術に成長した。

このチームは前にも、奇妙なものを使って本人同定を試みている。2012年にHolzはKinectとSurfaceを使って、人間がタッチスクリーンの上に立ったときの靴の形や大きさから本人性を判断しようとした。

[出典: AndroidAuthority]

[原文へ]
(翻訳:iwatani(a.k.a. hiwa