LINEのLetter Sealingその後

以前、これまで、LINEのE2EE実装「Letter Sealing」初見LINEのLetter Sealingに関するフォローアップと2回に渡り、LINEのE2EE実装である、Letter Sealing機能に関して取り上げてきたわけですが、以前にも増してメッセンジャーにおけるE2EEが一般的になってきました。以前はE2EEを実装したメッセンジャーアプリはSignalTelegramぐらいしかなかったのですが、今ではFacebook傘下のWhatsappにもSignalと同じ方式のものが実装されましたし、また、Facebook MessengerもまもなくE2EEが実装されるようです。他にもGoogleもビデオチャットアプリであるDuoはE2EEを使用している他、また今後リリース予定のメッセンジャーAlloにもE2EEの実装が予定されているようです。

さて、最近、LINEのEnginners’ Blogにおいてメッセージの安全性のさらなる強化:Letter Sealingの適用拡大という記事が公開されました。内容的にはLetter Sealing機能が更新され、デフォルトでE2EEが有効となり、また、音声やビデオ通話、及びグループチャットにE2EEが使用できるようになった、ということです。

今回の更新で、以前、指摘した、暗号化されているかどうかがわかりにくい、という問題が解決したと思われます。ただ、今回の更新で、暗号化されているのがわかるようになったのですが、以前の記事で「現時点では、Letter Sealingはテキストメッセージと位置情報に対してのみ適用されます。」となっていますが、これが現在どのような実装になっているのかが気になるところです。(今回の記事でこちらの件に関しての言及はなかった。)もし、引き続き、Letter Sealingが「テキストメッセージと位置情報の対してのみ」行われているのであれば、こちらは錯誤を招く表示になってしまいますので、こちらは「何が暗号化されるのか」の詳細を知らせて欲しいところです。

次に、せっかくE2EEを実装しているのだから、もっとアピールしてもらいたいところです。現在、定点観測できるいくつかのトークグループがありますが、半分程度、この機能が有効になっていないグループがあり、そのほとんどが恐らくアプリの更新を怠っているのが原因であると考えます。LINEのユーザーは特にユーザー層が広く、技術的リテラシーにばらつきがあり、こちらは更新を促す施策を是非考えて欲しいところです。

なぜGrub2の認証脆弱性は大きな問題ではないか

Linuxのブートローダー、Grub2にバックスペースを28回押すとレスキューシェルに入れてしまうバグがあるということがこの数日報道されています。

脆弱性があるということ自体に問題があるということを否定するわけではありませんが、まず、Grub2を含む、ブートローダーの認証を過信するのが問題です。実質的にブートローダーの起動パスワードが入力できる状態であるということは即ちハード自体へのアクセスがあることを意味します。ハード自体へのアクセスが行えるのであれば、ブートローダーをUSBドライブ経由などから読み込ませて起動すれば、レスキューシェルなど、簡単に実行できてしまいます。ハードのアクセスが物理的に行える以上、この脆弱性が存在しようがしまいが、本質的にはセキュリティには全く影響しないのです。

そのため、セキュリティ問題としてこの問題を解消するには次のような施策が必要になってきます。

  • ハードへの物理的なアクセスを制限する。
  • パーティションを暗号化する。

尚、Grub2の認証機能自体、そもそも幻想のセキュリティを提供する形になってしまっていますので、本来はこんな機能自体削除しまったほうがいいぐらいです。(カジュアルな運用でレスキューシェルへ簡単にアクセスできてしまうこと自体が問題になるのであれば、ブートローダーからレスキューシェルは取り外して、必要に応じてそれを有効にしたブートローダーを外部メディア経由で起動するほうが余程マシな運用です。)

OnionShareを使用した安全なファイル共有

OnionShareを使用することにより、簡単にファイルを共有することができます。

OnionShareはTor秘匿サービスの仕組みを使用しています。秘匿サービスを使用することにより、検閲システム等に影響を受けにくく、また、点から点を暗号化された接続で結ぶことにより、第三者にファイルを預けることなく、Torのネットワークを介して、データを転送することができるようになっています。

OnionShareを使用するのに必要なものは次の二点です。

上記をダウンロードし、インストールした後は、まずはTor Browserを起動します。

TorBrowser

Tor Browserが正常に起動したのを確認した後、OnionShareを立ち上げます。

OnionShare起動後

OnionShareでファイルを選択します。

OnionShareファイル追加後

Start Sharingボタンを押します。(●表示が黄色になります。)

OnionShareファイル公開準備中

●が緑色になったら表示されている.onionアドレスを読み、受信者に伝えます。(そのままコピーすることもできます。)

OnionShareファイル公開

受け取り側はTor Browserを開いて提供された.onionアドレスを開きます。

TorBrowserで表示したOnionShare

ダウンロードのボタンを押すとダウンロードが開始されます。尚、受信者側で次のような警告が表示されることがあります。(既定で表示される。)

TorBrowserダウンロード警告

これはファイルが持つ潜在的な危険性(例えば、実行ファイルなど)を警告するものです。ZIPファイルにはそのようなファイルが入っている可能性があるため、この警告が表示されるようになっています。ダウンロードするだけでは危険はありませんが、内容物に含まれるファイルが匿名性を損なわせる可能性があることを警告している文言です。

OnionShareダウンロード完了

既定では受信者がダウンロードを完了すると、自動的に公開は停止されます。Stop sharing automaticallyのチェックを外すと自動的に停止されないので、複数の人にダウンロードしてもらう場合は、このチェックを外す必要があります。(ファイルの公開が停止された後に、再公開すると別のアドレスが生成されます。)重要なのは相手がダウンロードを完了するまで、OnionShareの共有は有効にしておく必要があります。

このようにファイルを手軽に転送できますが、特徴として以下が挙げられます。

  • 点から点への暗号化接続
  • Torに接続できている限り、ポート転送などの設定は必要なし
  • サイズの制限なし(システム上のファイルサイズの制限などに依存します。転送速度は遅めになります。)
  • Hidden Serviceが備える高い匿名性(ただし、その匿名性は当然.onionアドレスを知らせる手段により変化します。)

恒久的に、特に不特定多数にファイルを提供する場合、Webサーバを使用したHidden Serviceサイトを構築する方がいいですが、手軽にファイルを特定の相手に転送するのには便利かと思います。

LINEのLetter Sealingに関するフォローアップ

9月1日にLINEのE2EE実装「Letter Sealing」初見という記事を書いて、そこに

(公式情報が投稿され次第、加筆などはする予定です。)

と書きましたが、本日、メッセージの安全性新時代:Letter Sealingという記事が公式ブログのLINE Engineers’ Blogで公開されてますので、公約通り、加筆します。

基本的、公式サイトで解説されているのはLetter Sealingはごく一般的な公開鍵暗号方式が使用されているということです。鍵交換方式はECDH、暗号化はAES-CBC-256HMACと、方式的にはOpenPGPなどで使われている機構とそう変わりません。(ECDHはちなみにGnuPG 2.1で対応しています。)

ここで気になってくるのはECDHを使っているという表記。もし、これを額面通りに受け取るのであればLINEの実装はPerfect Forward Secrecyを実装していない、ということになります。(もし実装しているんであれば、DHEなり、ECDHE使ってますって書くよね?)
PFSは最近のメッセンジャーの暗号化の実装では一般的なもので、セキュリティを高めるのに非常に重要な要素なので、この実装はぜひ検討していただきたいものです。

また、前回の記事でも指摘したように、メッセージが暗号化されているかどうかがわからないのがこのシステムの致命的なところですが、それに関しては修正が検討されているようなのでよかった。

なお、この手の情報を一般向けに取っ付き易く説明するのは非常に骨の折れる話です。LINEのエンジニアのブログではそのあたり、結構丁寧に解説しているので、この点は非常に賞賛できると思います。

Google Chrome、Linux下での速度問題のまとめと回避方法

(2016年2月22日更新)この問題を修正する変更が開発者により行われ、すでにソースコードに取り込まれています。この変更が実際のリリースに適応されるのにはしばらく時間がかかりますが、近いうちに修正が入るものと思われます。

最近のGoogle Chromeに、すでに何件か報告されている問題で最近原因が解明されたものがあり、その問題と取り敢えずの対処法に関してまとめます。

どういう問題なのか

Google Chromeのアドレスバー(Omnibox)の入力レスポンスがものすごく遅くなります。スペックにもよりますが、具体的には一文字入れるとそれが出てくるまでに数秒を要する、といった具合です。極端な場合には多大な遅延のせいで、入力される文字の順番が入れ替わってしまう場合もあります。(例えば、google.comと入力したつもりがgogole.cmoとなるなど)

また、インターフェース自体の再描画も全体的にもっさりとするため、メニューを開くのに遅延が出るなどの問題が発生し、全体的にGoogle Chromeメインプロセスが消費するCPUが高くなる傾向にあります。

原因は?

バグが報告されていたものの最近までその原因は特定はされていませんでした。1月6日にChromiumプロジェクトのKochi氏がこの問題がフォントのキャッシュがフォントのフォントファミリー名による参照によりキャッシュされていないとみなされ、再キャッシュプロセスが発生してしまうのが原因で発生しているということが報告されました。

つまり、まとめると以下のようになります。(Kochi氏が指摘する源ノ角ゴシック JPを使用した場合)

  • Google Chromeが源ノ角ゴシック JPを使用してフォントをレンダリングしようとする
  • Google Chromeが源ノ角ゴシック JPを使用しようと、そのフォントファミリー名のSource Han Sans JPで参照しようとするが、キャッシュされていないと見做し、キャッシュ動作(非常に重い)が発生する

というようなプロセスが発生し、これが一文字入力されるごとに発生していた、という問題のようです。

尚、上記に併せ、同氏によりコードの修正レビューが提出されていますが、すでにこの修正を含む、書き換え自体が予定されていることもあるようで、パッチとしての適応はされないようです。そのため、根本的な解決にはしばらく時間を要すると予想されます。

回避策

根本的な解決はコードに対処が入るまで行わられないものの、取り敢えず回避することは可能です。基本的にフォントのファミリー名が問題にならないフォントを使用すればいいわけです。尚、こちらで実験したところ、IPAフォントとその亜種ではこの問題が発生してしまうようです。(日本語環境ではこれらが指定されていることも多いでしょうから、この問題にあたってしまう人も多いかもしれません。)

回避方法

前述のように、この問題の影響の受けないフォントに置きかえてやるのが回避する方法になります。Gnomeを使用している場合、gnome-tweak-toolを使用し、UIが使用するフォントを問題のないものに置きかえる必要があります。gnome-tweak-toolは標準ではインストールされていないので別途インストールが必要です。

KDEの場合kde-config-gtk-styleをインストールした上で、外観設定の中のGTK設定のフォントを変えることで対応できます。

KDE GTK Config

フォント設定を例えば、Noto Sans CJK JPなどに置き換えることで対応可能です。

フォント設定

この変更を行い、右下の適応ボタンを押すことで変更が保存されます。尚、Google Chromeに対し、この変更を有効にするためには変更した後に、Google Chromeを再起動する必要があります。

Blenderを使用したNDVI画像の処理

この記事はBlender Advent Calendar向けに作成しました。本稿は元々Analyzing NDVI Imagery Using Blenderとして投稿していたものに加筆修正を加えたものです。

Blenderの本領である3D作成とは違った趣向ですが、レンダリングノードがどのくらい汎用性があるか、ということに関して示すことができましたら嬉しいです。

先ずはNDVIに関して軽く解説。NDVIはNormalized Difference Vegetation Indexの略で、正規化植生指標という植物の量や活力を表す値です。具体的には赤の可視光と近赤外線を測定することにより得る値となります。

国土環境モニタリングのページにその計算方法などが掲載されています。

どのようにして撮影するのか

一般的なカメラの素子は赤外線を捉えることができますが内部にそれを遮断するフィルタが入っており、そのまま撮影しても必要な光成分はほとんど撮影されません。Public Labはそれを分光するためのフィルタを販売しており、それを使用し、カメラを改造するか、改造済みのカメラを入手することができます。このカメラでは赤外線成分を赤チャンネル、可視光線を青チャンネルに記録します。

基本的原理は同じなので、衛星などの元データなどのデータも流用可能かとは思いますが、データ構成により調整を行う必要があるかもしれません。

Blenderを使用しての処理

ここで使用する画像はInfragramカメラに付属のサンプル画像を使用します。このカメラで撮影すると、以下のような画像が撮影できます。

撮影画像

NDVI画像を抽出するのにはノードでNDVI変換を定義しました。

NDVI変換ノード

このノードグループからは以下のような出力が得られます。この画像をColor Rampなどと合成することにより擬似色画像を構成することができます。

NDVI出力画像

以下はColor Rampを当てはめた例です。活性度に応じて白や緑に表示されています。

NDVI擬似色画像

Public Labでは撮影した画像を処理するサービスがありますが、Blenderで処理することにより同様の画像をローカルに処理することができます。

Infragram.org的 その1

Infragram的 その2

Blenderではノードを設定し、組み合わせることで、目的に応じた映像を出力することができます。

ノード設定

例えば以下は白黒の可視光線画像にNDVI画像を合成した画像です。

活性を示したオーバレイ画像

この画像では植物が活発と思われる部分がはっきりとハイライトされるため、存在する植物などを表示することができます。

以下、使用したBLENDファイルです。

infragram-2014082702.blend.zip

BlenderでNDVI処理する利点

  1. 柔軟性のある加工を施すことができる。
  2. Packすることにより、共同作業者などと単一のファイルをやりとりすることができる。
  3. NDVI動画画像も静止画と同じぐらい簡単に加工可能。(タイムラプス映像や気球映像などの加工も容易)ただし動画を使用した場合現状Packされないことにご留意下さい。
  4. 非破壊的に処理を加えることができるため、処理の切り替えができるほか、またどのようにして最終画像に至ったかということがファイルに含まれるため、いわば自己ドキュメンティングなファイルを配布することができる。

応用

同様のプロセスを使用して、その他の分野の加工でも、光成分に関する加工を行うことができます。カラーランプは色を一定の色のスケールに割り当てることができるため、例えば犬から見た景色、などもシミュレートしてみることが可能です。

犬が見る街

明日はnecoganeさんのテクスチャ作成方法(自己流)について、ということです。

メールをGnusに移行

(この文書はI Transitioned Local E-mail Management to Gnusの和訳版です。

これまでメールはGmailやGoogle Apps(最近はGoogle Apps for Workに変わったんでしたけ)を公私ともに使用しているため、ほとんどGmailのインターフェースで使用していたのですが、ローカルなメール環境に関しては結構模索を行っていました。Mozilla Thunderbirdなども使うことはあったのですが、結構重いのが欠点でした。

個人的には以下のような要件を満たす必要があります。

  1. 大量のメール(数百件/日)を処理できること。全て深く読むわけではないですが、ML内のメールを高速に走査できることが重要。
  2. 一般的なプレーンテキストのメールを処理し送信できる機能(詳細後述)
  3. MacとLinuxを中心に使っている関係上、これらのプラットフォームをサポートしていること。(Microsoft Outlookが絶対に候補に上がらないのはこの理由の他にも過去の苦い経験もあります。上記1番の使用に耐えうるものでもないですし……。
  4. OpenPGPをサポートすること
  5. 複数アカウントをサポートすること(個人・仕事)

基本的には3番目のポイントで選択がかなり狭まりました。それで考えたのは、どうせマルチプラットフォームでEmacsを毎日のように使っているんだからこれで内蔵のものを使っちゃおうということでした。

「こうして越前康介はGnusを手に入れた」

ということ(?)で、個人的にはGnusを使う利点としては以下のようなものでした。

  • 上記の要項を全て満たした。
  • テキスト編集はテキストエディタである関係上、非常に強力な機能を備えている。
  • 隠し事が少ない分、細かい部分まで制御できる。(反対にいうとそれだけ操作性が粗い、ってことですが。)
  • それなりにEmacs Lispをいじったことがあるのでそこそこの改良を加えることができる。
  • Org-modeと連携できる!(リンク設定などが可能。)

今回の検討で考慮に入れなかったのは以下の通り:

  • 検索能力……どうせGmail系なんだから、餅は餅屋に任せるやりかた。結局はある程度の自動タグのほかはフラットに時系列に行っているので数週間前のメールは検索に頼った方が速いので。反対にいうと一覧表示で見つからないほど古いメールは古すぎて役に立たないか、それ以降一度もタッチしないことがほとんどなので、その管理に労力は使ってません。一応残してはいますが。
  • 通知機能……スマフォやスマートウォッチが知らせてくれるので使ってません。一応Gnus内でこれを設定することは可能のようですがあまり意味はなさそうなのでやってません。
  • リッチテキスト編集機能……HTMLやリッチテキストを送ることはないので。自分をよく知っている人ならわかるかも知れませんが、このようなマークアップでのメールは基本的に送信しません。あっても時々シンプルなマークダウンを行うぐらい。自分からのHTMLメールが届いた、という人はそれはほぼ100%、Gmail for Androidがそのように送信してしまったからです。あのアプリ、プレーンテキストしか送れないくせにHTMLメールで送信するんですよね。閲覧はブラウザを通してすることは可能です。普通はHTMLメールは互換形式としてプレーンテキストとしてついてくるので、それを閲覧しますが、プレーンテキスト版がついてくるので時々行儀が悪い(もしくは設定が不完全)なメーラーがHTMLだけで送ってくることがあります。ちなみにそういうメールは無視されるか、良くても閲覧順の最後尾に容赦なく持っていきます。

なので、上記のような機能に興味がある人は多分この記事は面白くないので、さっさとご退場をおすすめします。

さて、複数のGmail/Google Appsのアカウントを使用しているため、SMTPの使い分けが必要になってきます。この実現には
emacs 30 Day Challengeのusing ‘gnus’ to read mailという記事が参考になりました。ここでは自動的にSMTPアカウントを切り替える方法が書かれていますが、送信の規則性が非常に複雑なこともあり、ここは手動処理の余地を個人的には残しています。つまり、X-Message-SMTP-MethodやFromの変更をする方式になっています。このサイトに含まれるコードは誤って存在しないアカウントなどからメールを送信しないような対策として使用しています。この設定は以下のような感じです。

(defun gnus-set-mail ()
  (interactive)
  (message-goto-from)
  (kill-whole-line)
  (insert "X-Message-SMTP-Method: smtp smtp.googlemail.com 587 example@gmail.com.com\nFrom: Example \n\n")
  (message-goto-body)
  )

ちなみに、KDEを使っていますが、Ctrl-Alt-TはUnityみたいにターミナルを起動する設定になっていますので、Gnusでのスレッド表示切り替えはC-M-tからC-c C-tに置き換えています。ちなみにこの設定は簡単……。

(define-key gnus-summary-mode-map "\C-c\C-t" 'gnus-summary-toggle-threads)

GnusにはMMLという書式が組み込まれているため、MIME構造を柔軟にいじることができます。例えばMIMEパートを自由に入れたりといったようなことが可能ですが、基本的には添付ファイルの扱いを細かく制御するために使っています。

MIMEパートを設定してみる
MIMEパートを設定してみる

とりあえずはうまく動いていますが、今後は必要に応じて細かい挙動をカスタマイズしていく予定。