LINEのタイマートークで思うこと

LINEに新しく、タイマートークという機能が追加されました。

現在、「日本、中国以外でご登録いただいているお客さま」以外にしか使用可能になっていないそうですが、そのうちオープンになるんじゃないでしょうか。(中国では永遠に使用できないかも知れませんが)

どういう機能かというとSnapchatのように制限時間をつけたメッセージを送れるということです。(当然、両環境が最近のバージョンかつ上記の地域制限に引っかかっていない地域のユーザーである必要があります。)

使用を試みると以下のような表示がでます。

Screenshot_2014-07-31-21-24-22

これを見るとエンドツーエンドで暗号化しているようです。メニューにも暗号化キーを表示できるようになっています。見ると128ビット長のユーザー固有の鍵が使用されているです。

Screenshot_2014-07-31-21-24-36

タイマートークのメッセージを受信すると以下のようにタイマーメッセージであることが表示されます。メッセージの内容を通知する設定になっている場合もタイマーメッセージの場合、内容は表示されません。

Screenshot_2014-07-31-21-25-33

メッセージをタップすると双方でカウントダウンが表示されるのが確認できます。この長さは2秒から1週間まで選択できるようになっているようです。

Screenshot_2014-07-31-21-25-45

さて、この機能なのですが、一応エンドツーエンドをLINEで実現しようという機能は評価できるのですがいくつか思いつく問題や懸念としては……。

  1. 暗号が正しく使用されているか、また運営会社や当事者以外の機関(政府機関を含む)の鍵に対して勝手に暗号化を行っていないか
  2. 暗号鍵が変更できない使用になっているが、乱数などでちゃんと生成されたものなのか
  3. メッセージはきちんとソルトされているか

1に関してはこれはクローズドソースの宿命なので、回避のしようのない問題と言えます。これは別にLINEに限らずWindowsなどのOSを含め、どのようなソフトでも当てはまります。
2に関しては、いくら暗号を使用していたとしても暗号鍵が予想できる情報から推測できるものが生成されるような仕様になっていると無駄になってしまいます。また、正しく実装された乱数から取り出されたものであっても、変更が行われない仕様になっていると暗号鍵が漏洩した場合、役に立たなくなってしまいます。これに関しては手動で鍵を再生成し拡散できるような仕組みが欲しいところです。どちらにしても署名目的には使用していない仕様と思われますので、鍵を定期的に再生成するぐらい仕組みでもいいかと思います。
3に関しては特にLINEの場合、既知のスタンプなどパターン化されたメッセージが頻繁に使用されるシステムのため、ソルトがきちんとなされていないとリプレイ攻撃などが容易に行われてしまいます。そのため、他のソリューション以上にソルトが重要であるかと思われます。

尚、評価できる点としてはスクリーンショットの防止・通知など幻想のセキュリティが想起されるような実装を行っていないところです。Snapchatではこれが行われていますが、実際のところその通知がないからと言ってスクリーンショットが撮られていない、という保証はありませんし、基本的に他のユーザーに送られた場合、送られた情報はそのユーザーがどうとでもできる、という前提に使われるべきです。将来的にこれらが実装されるのかは分かりませんが、現時点で敢えてそれらに関して対策を行っていないのはある意味まともとも言えるかも知れません。ただ、ヘルプなどでスクリーンショットなどの撮影が可能なので、タイマーメッセージで送付先ユーザーがそのメッセージを受け取った後は必ずしも安全でない、ということは示されるべきであると考えます。

SVNファイル群よりファイルを復旧させる方法

先日、あるソースファイルを作業していたのですが、コンパイルに必要なファイルが不足している、おまけにすでにその作成者とは連絡がつかなくなっている、という事態に陥りました。ファイルを調べてみるとファイルの実体に関しては消去されていたものの、隠し属性となっていた.svnディレクトリがそのまま残されていることが判明し、それをリカバーすることで対応することができました。

以下は備忘録も兼ねたその手段に関してです。

SVNは元のファイルはハッシュ化されてpristineディレクトリに含まれています。ただ、問題はこのディレクトリは全てハッシュ化されているため、そのままコピーすることができません。そこで、wc.dbから対応表を得ることにしました。

sqlite3 .svn/wc.db "select * from work_queue

対応表はファイル名やファイルハッシュが関連付けられているのでこれをパースすることにより、実体にコピーしていきます。


#!/bin/sh

for line in cat list.txt; do
echo Processing $line
filedest=$(echo $line | awk -F"|" '{print $1}')
filehash=$(echo $line | awk -F"|" '{print $3}')

if [ ! -d ../../$(dirname $filedest) ]; then
    echo Making missing ../../$(dirname $filedest)
    mkdir -p ../../$(dirname $filedest)
fi

shash=$(echo $filehash | awk -F"$" '{print $3}')
cp -R $(echo $shash | cut -c1-2)"/"$shash.svn-base ../../$filedest

done

これで全ファイルを取り出すことに成功。もっとエレガントな方法もあるかもしれませんが。

Googleのレンズぼかし機能のファイル構造

Google Cameraの目玉機能としてレンズぼかし機能があります。

スマフォのカメラで擬似的に高深度の写真を取る機能です。

例えば、次のような写真が撮れます。

レンズぼかしで撮影

この機能の方法はGoogleのブログで解説されていますが、後からフォーカスを設定できたりと面白いのでどのようなファイル構造になっているかを調べてみました。

Exiftoolからの出力はこんな感じ。

ExifTool Version Number : 9.46
File Name : IMG_20140416_181937.jpg
Directory : .
File Size : 909 kB
File Modification Date/Time : 2014:05:01 18:06:55-07:00
File Access Date/Time : 2014:05:01 18:06:57-07:00
File Inode Change Date/Time : 2014:05:01 18:06:55-07:00
File Permissions : rw-rw-r--
File Type : JPEG
MIME Type : image/jpeg
Exif Byte Order : Big-endian (Motorola, MM)
GPS Latitude Ref : North
GPS Latitude : 47 deg 36' 45.04"
GPS Longitude Ref : West
GPS Date Stamp : 2014:04:17
GPS Longitude : 122 deg 20' 0.10"
GPS Time Stamp : 01:19:28
Modify Date : 2014:04:16 18:20:08
XMP Toolkit : Adobe XMP Core 5.1.0-jc003
Blur At Infinity : 0.017260155
Focal Distance : 18.298956
Focal Point X : 0.5
Focal Point Y : 0.5
Mime : image/jpeg
Format : RangeInverse
Near : 11.670198440551758
Far : 53.99827575683594
Mime : image/png
Has Extended XMP : 16D07BD6549EF7884C2D15AB36A95F28
Data : (Binary data 369408 bytes, use -b option to extract)
Data : (Binary data 204032 bytes, use -b option to extract)
JFIF Version : 1.01
Resolution Unit : None
X Resolution : 1
Y Resolution : 1
Image Width : 1536
Image Height : 2048
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
GPS Date/Time : 2014:04:17 01:19:28Z
GPS Latitude : 47 deg 36' 45.04" N
GPS Longitude : 122 deg 20' 0.10" W
GPS Position : 47 deg 36' 45.04" N, 122 deg 20' 0.10" W
Image Size : 1536x2048

メタデータ部分に二つのバイナリデータが存在するのが確認できます。これを出力してみるとこれらはXMPとして記録されているデータであることがわかりました。一つはPNGファイル、そしてもう一つがJPEGファイルです。

まずはJPEGファイルを出力してみました。

exiftool -X -b IMG_20140416_181937.jpg | sed -n '/XMP-GImage:Data/{s/.(.)<\/XMP-GImage:Data>.*/\1/;p}' | base64 -d > IMG_20140416_181937_xmp.jpg

GImage:Dataに含まれるのは以下の画像でした。つまり、これはカメラが見たそのものの画像となります。

GImage:Data

もう一つPNGとして記録されている画像は次のように出力しました。

exiftool -X -b IMG_20140416_181937.jpg | sed -n '/XMP-GDepth:Data/{s/.(.)<\/XMP-GDepth:Data>.*/\1/;p}' | base64 -d > IMG_20140416_181937.png

こちらの名称はGDepth:Dataで、被写体の距離が示されたもので、色が濃いほど近くのものとなります。

GDepth:Data

この機能を使用して撮られた写真は単体で深度情報を含んでいるため、例えば他の機種で撮った写真をGoogle Cameraがインストールされた機種にコピーなどをするとそのままフォーカスを再度変えたりすることができます。Google+なんかでブラウザ上でこれができたら面白いと思うのですが、必要な情報は全てファイルに内包しているということもあり、実現されるかもしれません。

DockerでTorアプライアンス(的なもの)を作ってみる

最近個人的に注目しているものにDockerがあるのですが、これ、簡単にいうと、Linuxの構成をコンテナ化して、システム間での可搬性を実現するシステムです。コンテナ内のプロセスは隔離されるため、要は仮想環境を構成するシステムなわけですが仮想マシンと違って環境を走らせるオーバーヘッドが非常に軽く、普通のソフトウェアを動作させる感覚でコンテナが実行できます。また、Ubuntuを使っていてCentOSやFedoraの環境を構成したい、というようなことも可能です。(Linuxをベースにして走らせる仕組みになっていますので、例えばWindowsを走らせたり、反対にWindowsからコンテナをそのまま実行したり、ということはできません。その場合は仮想環境を作るソフトが必要になります。)

どういうことに使えるか、というと

  • 現場環境に近いテスト環境を作成する
  • 環境をローカルで構築し、Dockerがデプロイされている環境にそのまま移植する)
  • メイン環境に手を加えずにシステムに変更を加えるようなソフトウェアを利用する(特にroot権限を要するようなプロセスを走らせないといけない場合、-vオプションなのでファイルシステムのアクセスを与えない限りファイルのアクセス権限はコンテナ内に制限されるため、比較的安全に実行できます。極端な話、コンテナ内でrm -rf /*が実行された場合でも外部にコンテナ外には影響は及びません。)

など、いろいろと考えられると思います。例えば、PHP実行環境のバージョンが異なったウェブサーバを立ち上げる、ということができるようになります。

今回これを利用してTorのアプライアンス的なものを作ってみることにしました。

Torのファイル自体は公式レポジトリのものを使用します。

空のディレクトリにDockerfileというファイルを作成し、以下のように記述しました。

FROM ubuntu:13.10
MAINTAINER Hideki Saito 
RUN echo "deb http://deb.torproject.org/torproject.org saucy main" >> /etc/apt/sources.list
RUN gpg --keyserver keys.gnupg.net --recv 886DDD89
RUN gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add -
RUN apt-get update && apt-get install -y tor
ADD files/torrc /etc/tor/torrc
EXPOSE 9050
ENTRYPOINT ["tor"]

このスクリプトによりTorのレポジトリを追加し、インストールした上で、目的に書き換えたfiles/torrcを含めた上でコンテナ化する、という設定になっています。レポジトリがない場合でも、依存を設定した上で、最新ソースを引っ張り、コンパイルした上で配置、クリーンアップしてコンテナ化する、といったようなことももちろん可能になります。このファイルを作成した上で、files/torrcにTorの設定を記述し、docker build -t “hsaito/torbox” .を実行しました。すると自動的にapt-getによるファイルの入手や、インストールが行われ、ローカルのイメージリストにhsaito/torboxが作成されます。この場合はhsaito/torboxとして作成し、Docker Indexにプッシュしました。このプッシュという方式はGitによく似ています。プッシュやプルの場合、差分のみが送受信される形になります。

Dockerが強力などが派生環境を非常に手軽に作れることです。例えば、今回の例の場合、アプライアンスとしてのSOCKS環境ではなくて、Tor relayサーバをコンテナ化したいとします。そうなると必要なDockerfileの定義は以下のようになります。

FROM hsaito/torbox
MAINTAINER Hideki Saito 
ADD files/torrc /etc/tor/torrc
EXPOSE 9001
ENTRYPOINT ["tor"]

この場合、上記と違い「FROM hsaito/torbox」を設定しているため、すでにhsaito/torboxを持っている場合はそれが再利用され、差分だけがダウンロードされます。(こちらはhsaito/torbox-relayとしてプッシュしました。)そのため、レポジトリからTorをインストールしたりする定義は行っていません。変わっているのは独自のtorrcを差し替え、露出されるポート番号を変更しているだけになります。実は上記の場合も元のイメージの「ubuntu:13.10」を前提に作っています。これを利用することにより、例えばウェブサーバを含んだコンテナをまず作成しライブラリのみを差し替えた差分コンテナを作成する、という方法をとることにより、楽にコンテナ環境が作成・管理できます。

ちなみに上記はそれぞれdocker pull hsaito/torboxとすることでダウンロードし、docker run -d hsaito/torboxなどで実行できます。(relay版を使用する場合はhsaito/torboxをhsaito/torbox-relayに置き換えて下さい。

UUIDの生成

最近UUIDを生成することが多いので、uuidgenを使って生成していたのですが、使用しているEmacsより簡単に起こす方法を模索していたら、以前Ergoemacsでその記事があったのを発見。

例として以下のようなものでした。

(defun insert-random-uuid ()
  (interactive)
  (shell-command "uuidgen" t))

まあ、普通にuuidgenを呼び出しているコードなので、これでも全く問題がないわけですが、必要になったときのために、Emacs内で関係させる方法を見ていると同記事にいくつか例がありました。

掲載されているコードですが、4番目のセクションの最初の文字が必ず「a」が出力されるようになっています。別にUUIDの規格上正しいものが出力される(この文字は「8」、「9」、「a」、「b」のいずれかである必要がある)のですが、固定はちょっと気持ち悪いので以下のように変更し、規格上正しいもののいずれかが出力されるように変更しました。

;; by Christopher Wellons. 2011-11-18. Editted by Xah Lee.
;; Edited by Hideki Saito further to generate all valid variants for "N"
;; in xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx format. 
(defun insert-uuid-internal ()
  "Insert a UUID. This uses a simple hashing of variable data."
  (interactive)
  (let ((myStr (md5 (format "%s%s%s%s%s%s%s%s%s%s"
                (user-uid)
                (emacs-pid)
                (system-name)
                (user-full-name)
                (current-time)
                (emacs-uptime)
                (garbage-collect)
                (buffer-string)
                (random)
                (recent-keys)))))
    
    (insert (format "%s-%s-4%s-%s%s-%s"
                    (substring myStr 0 8)
                    (substring myStr 8 12)
                    (substring myStr 13 16)
                    (format "%x" (+ 8 (random 4)))
                    (substring myStr 17 20)
                    (substring myStr 20 32)))))

まあ、uuidgenが使える環境であれば/dev/urandomをソースとするuuidgenを使用したほうが乱数源などを考えると一番ベストなわけですがUUIDを生成する程度のことであればそれほど大差はないかもしれません。

完全なコードHidekiBinにおいてあります。

Raspberry Piを使用したリモートVPN接続ポイントの構築

先日、固定IP接続を実現するために職場で使用しているVPN接続サービスのルータ配置を自宅に移動しました。現在職場はオフィスビルに立地しているにも関わらず、Clear(WiMax接続サービス)以外に現実的に使用できる回線がなくローカル、リモートの接続とともにボトルネックになりつつあったからです。VPN接続ポイントを外に配置することにより、アクセススピードの高速化を実現することになりました。

職場に設置していた時にはLinuxを走らせているPCでアクセスを制御していましたが、自宅に設置するにあたり、より電源効率の良い、ポータブルなものにする、ということで、Raspberry Piを採用することにしました。(一応自宅にもLinuxマシンは常時走っているのは走っているのですが、責任分界的にも自宅LANと会社LANは完全に隔離しておきたかった、という狙いもあります。)

リモートからVPNにアクセスするにあたっていろいろと検討した上で、最近オープンソフトされたSoftEtherを採用することにしました。

  • 設定が比較的簡単であること
  • OpenVPNやL2TP/IPSecなどを使用できること。特にMac用のSoftEther接続ソフトは現在提供されていない(サーバはある)ため、これは重要な判断基準となりました。

また、以前、UT-VPNは試用していたことがあるため、SoftEtherはそれに近い、ということも判断の一つでした。

SoftEtherの設定は非常に簡単に行えましたが、カーネルモードのNATが使用されている場合、スタックの関係上からか、DHCPがVPNより下のレイヤーからIPを取得してしまう問題があり、DisableKernelModeSecureNATを使用し、ユーザーモードでNAT環境を作ることで解決しました。SoftEtherの独特な設定環境(例えばnattableとsecurenattableが別の意味を持っていることなど)で少し混乱があり、NATが有効になっていなかった、という問題などはありましたが、無事環境を構築することができました。

パフォーマンス的にどこまでいけるか、という不安はありましたが、接続時などのCPUのロードは20%でぐらいで、問題なく使用できると判断でき、専用のRaspberry Piを購入し、現在実運用中です。

久しぶりに日本から注文

Clannadと聞いて……。
結構好きなのでちょっと迷ったけど買った、光の軌跡。描き下ろしなんだろうけど、この表紙、可愛い。

最近はAmazon、海外発送が少し安くなっている感じがする。

あけましておめでとうございます

あけましておめでとうございます。こちらではまだあけていませんが。

今回も紅白の同時放送を見ていました。去年はGoogle+のコミュニティを使用して独り言などを流していましたが、今年はHidekiBinを使用しました。
当該ペーストは一年で消えますので、PDF版も保全。
第64回紅白歌合戦視聴ログで見られます。(ChromeのPDF保存機能が便利。)