はじめに

最近、TwitterやGitHubなどと連携できる公開鍵基盤Keybaseに招待していただいたので、このKeybaseがどのようなサービスであるのかを、前提となる公開鍵暗号や公開鍵基盤などから順を追いつつ軽く紹介していきたいと思います。

共通鍵暗号と公開鍵暗号

暗号にはおおまかに二種類があり、共通鍵暗号（対称鍵暗号）と公開鍵暗号です。これらの特徴を次のようになっています。

共通鍵暗号

共通鍵暗号はDESやAESが有名で、次のような特徴を持ちます。

同じ鍵（秘密鍵）を使って暗号化と復号化¹を行う
後述する公開鍵暗号に比べて一般に高速である
あらかじめ、暗号通信を行う際に秘密鍵を安全な方法で共有する必要がある

公開鍵暗号

公開鍵暗号はRSAが有名で暗号化に用いる公開鍵と復号化に用いる秘密鍵の二つの鍵を使うのが特徴です。

復号化に専用の鍵を使うので、秘密鍵を安全な方法で共有する必要がない
共通鍵暗号に比べて、一般に低速である
署名に使うこともできる

公開鍵基盤（PKI）と中間者攻撃

さて、公開鍵暗号のおかげで共通鍵暗号のように鍵を安全な方法で事前に共有する必要はなくなりましたが、次のような課題が生まれました。

ある公開鍵が、本当に通信相手の公開鍵であることを保証できない

これができないと、中間者攻撃ができてしまいます。

中間者攻撃

中間者攻撃とは、ある人物アリスとボブが通信を行っているとして、この通信を傍受・改竄できる攻撃者マロリーが二人の中間に割り込んで次のような攻撃をします。

アリスはボブに公開鍵Aを送信する
マロリーは公開鍵Aをマロリーの公開鍵Bへ改竄する
ボブは公開鍵Bを受信する（ボブはアリスの公開鍵と考えている）
ボブは公開鍵Bを使って、メッセージMを暗号化した結果Eをアリスへ送信する
マロリーはマロリーの鍵で暗号化されたEを復号化してMを取り出し、改竄した結果M'を生成し、それをアリスの秘密鍵Aで暗号化してアリスへ送信する
アリスは送信された暗号文を復号化して、メッセージM'を受信する

このように、ボブは公開鍵Bが本当にアリスのものである、ということを判断できないと、このようにしてマロリーに情報を傍受されたり改竄されたりしてしまいます。中間者攻撃を防ぐひとつの作戦として、公開鍵基盤があります。公開鍵基盤があれば、ボブは受信した公開鍵Bが本当にアリスの鍵であるのかを問い合せて、公開鍵Bが第三者の鍵であると気がつきます。

SNSとの連携

Keybaseも公開鍵基盤の一つなのですが、これはTwitterやGitHubなどといったSNSのアカウントと公開鍵を紐付けます。このようにすることで、例えばあるTwitterアカウントを持つ人間と公開鍵暗号によるメッセージの交換を行いたいときに、あるTwitterアカウントと公開鍵を紐付ける公開鍵基盤になります。

このKeybaseですが、紐付けの仕方におもしろさを感じましたので、次のSNSアカウントの紐付けについて紹介したいと思います。

Twitter
GitHub
ドメイン

また、Keybaseは現在（2015年9月）この他にも次のようなSNSに対応しています。

reddit
coinbase.com
hacker news
自分のウェブサイト
bitcoin address

Twitterとの連携

このようなツイートを行うことで連携します。

Verifying myself: I am yyu on Keybase.io. lGcJIJfXwJ12AJpyOIQbfUIz3_xpzTUJSSOS / https://t.co/B8mVeDB817
— 吉村優 (@_yyu_) 2015, 9月 20

GitHubとの連携

次のような投稿をGistに行います。

Keybase proof

I hereby claim:

I am yoshimuraYuu on github.
I am yyu (https://keybase.io/yyu) on keybase.
I have a public key whose fingerprint is F299 3A15 492A 691B C4EE 1919 3730 168B 63BE ABA3

To claim this, I am signing this object:

{
    "body": {
        "key": {
            "eldest_kid": "0101514b12352d78ca91fcc55e5943d4a82f388d89ba10f8a8c04c67d529529301b40a",
            "fingerprint": "f2993a15492a691bc4ee19193730168b63beaba3",
            "host": "keybase.io",
            "key_id": "3730168b63beaba3",
            "kid": "0101514b12352d78ca91fcc55e5943d4a82f388d89ba10f8a8c04c67d529529301b40a",
            "uid": "a5abc00759ab7935959fe9c9e7c06119",
            "username": "yyu"
        },
        "service": {
            "name": "github",
            "username": "yoshimuraYuu"
        },
        "type": "web_service_binding",
        "version": 1
    },
    "ctime": 1442470224,
    "expire_in": 157680000,
    "prev": "1c9cac05eb3ce4d6435b9aeca57e2416c5ebfe93ff555f418932f1cd0a8b4e1c",
    "seqno": 2,
    "tag": "signature"
}

with the key F299 3A15 492A 691B C4EE 1919 3730 168B 63BE ABA3, yielding the signature:

And finally, I am proving ownership of the github account by posting this as a gist.

My publicly-auditable identity:

https://keybase.io/yyu

From the command line:

Consider the keybase command line program.

# look me up
keybase id yyu

# encrypt a message to me
keybase encrypt yyu -m 'a secret message...'

# ...and more...

ドメインとの連携

ドメインの設定で次のようなレコードを追加します。

txt @ keybase-site-verification=2XGrnKYkYX33RHB6Pk-Qm3OmJGQcjGncCgL1SyrfBtU`

暗号通信を行ってみる

実験として、僕が僕に対してメッセージを送ってみたいと思います。

宛先を自分にして、送りたいメッセージを投入します。

そして“Encrypt”ボタンを押せば、暗号文が生成されます。

出力された暗号文はこちらになります。

これをログインして、復号化してみます。メッセージとKeybaseのパスワードを入力して復号化します。

暗号化と同じように“Decrypt”ボタンを押せば復号化が完了します。

きちんと元のメッセージが復号化されています。

まとめ

KeybaseはSNSと連携した公開鍵基盤です。今回は紹介しませんでしたが、Keybaseを使っている人の間で署名をすることもできるので、メッセージを本当にその人が発信したのかが重要な局面で活躍する可能性もあります。
Keybaseは現在、招待制でメンバーを募集しているので、興味のある方は知っている人をKeybaseで検索して招待してもらうとよいと思います。

この記事では“decrypt”を「復号化」と訳すことにしますが、日本語としては「復号」が正しいという主張もあるようです。この記事では暗号技術入門第3版秘密の国のアリスや暗号と確率的アルゴリズム入門―数学理論と応用で採用されている「復号化」という言葉を使いますが、個人としてはどちらでもよいと思います。 ↩

SNSなどと連携できる公開鍵基盤“Keybase”の紹介