[レポート] セキュアなLINE バックアップを活用したシームレスな端末移行 #linedevday_report

2019年11月20日（水）・21日（木）にLINEのデベロッパーカンファレンス「LINE DEVELOPER DAY 2019」が開催されました。本記事ではセッション「セキュアなLINE バックアップを活用したシームレスな端末移行」をレポートします。

LINE DEVELOPER DAY 2019

#イベント

#勉強会

#LINE

諏訪悠紀

2019.11.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

セキュアなLINE バックアップを活用したシームレスな端末移行

2019年11月20日（水）・21日（木）にグランドニッコー東京台場でLINEのデベロッパーカンファレンス「LINE DEVELOPER DAY 2019」が開催されました。

LINE DEVELOPER DAY 2019

本記事は、セッション「セキュアなLINE バックアップを活用したシームレスな端末移行」をレポートします。

スピーカー

Charles Hubain [LINE セキュリティ開発チーム Senior Security Engineer]

セッション概要

LINEは、ユーザーのプライバシーの厳守とセキュリティの強化に全力で取り組んでいます。その成果として、コミュニケーションアプリ「LINE」では、ユーザー間やチャットグループ内で送られたテキスト・メッセージはエンドツーエンドで暗号化されます。そのため、万が一LINEのインフラが不正にアクセスされた場合でも、外部または内部からの攻撃者は暗号化されたメッセージしか見つけられません。しかしこの機能は、端末間のアカウント移動を複雑化させます。つまり新たな端末は、古い端末の秘密の暗号鍵無しではサーバーに保存された暗号化メッセージを解読することができないのです。この重要な課題は、「どうすればエンドツーエンド暗号を危殆化することなくLINEのインフラに秘密鍵のバックアップを取ることができるか」など技術的な回答を必要とするUX（ユーザーエクスペリエンス＝ユーザー体験）の問題です。本セッションでは、UXとセキュリティの観点からいくつかの解決策を紹介し、クリプトグラフィ（暗号学）・エンジニアリングやハードウェアセキュリティモジュール（HSM）、厳しい監査実務により、UXとセキュリティを両立する方法についてご説明します。

スライド

レポート

自己紹介
- 前職はパリでセク入りティコンサルタント
- ソフト、ハードの実装の監査
- 信頼性を確実にする仕事
- リバースエンジニアリングのツールも開発していた（GitHubでOSSとなっている）
壊すことと作ることの違い
- 壊すことは楽しい
- しっかりビルドするというところにも関わる
- 壊すのは得意だねと言われたがビルドもした方が良いと言われた
- ハックは楽、実装に比べると
- 単一の障害点を見つければ良い
- 作る方が違う
- セキュリティの高いものを作れば長期的な価値がある
- ビルドをすることに充実感を感じるように
大企業のセキュリティ
- セキュリティ担当がいるが得意なものにフォーカスして欲しい
- 実践としては
  - 開発チームは知識がかけているtコオrがある
  - スペックを誤解することがある
  - 開発チームなわけで、プライオリティは他にある
  - 全てを終わらせるのには時間が足りない
  - 近道をしてしまう、セキュリティがおざなりになる
  - セキュリティのミスを犯してしまう可能性もある
- セキュリティ開発チーム
  - デザインするだけではなく、機能をデザインする
  - 開発チームの責任になる
  - モジュールとしてまたはマイクロサービスとして作る
  - 開発チームが統合していく
  - 毎日直接リスク管理、リスク解析している人と話をしている
  - 半年前にできたばかり
  - 複数のプロジェクトをてかげている
    - パスワードレスの認証（FIDO2）
      - FIDO2のモジュールを作ってLINE Pay開発チームが統合
    - E2Eキーバックアップ
    - バンキングのプロジェクトのサポート
- LINE Letter Sealing
  - E2Eメッセージの暗号化
  - 暗号の話に入っていく
    - 楕円曲線暗号
    - 各ユーザーのデバイスが
    - 公開鍵は全共有、秘密鍵は
    - まずそれぞれの公開鍵を公開する
    - 自分たちの秘密鍵を使って開ける
    - 対象回鍵暗号でも開けられる
    - LINE Serverでやり取りする
  - LINEで実装しているのはE2E
  - 非対称の鍵交換
  - 課題もある
    - 秘密鍵を特定できない
    - 暗号メッセージしか保存していない（プライバシーを確実にできる、センシティブな情報を保管しなくて良い）
- アカウント移行
  - 例 : アリスが新しいデバイスを購入した
    - デバイス同士でデータを移行したい
    - サーバーは秘密鍵を持っていない
    - Letter Sealingのメリットを活かせる
  - 古い鍵をどのように移行するか？
    - 難しい問題
    - デバイスをもう持っていない場合もある
    - プラットフォーム間を出る場合もある（iOSからAndroidにスイッチする場合）
    - 内部共有モデルにも対応する必要がある
- The Enemy Whithin
  - 多層防御
    - セキュリティのパターン
    - 他の層があるので保護できる
  - 内部共有モデル
- UX vs Security
  - どこで妥協するか
  - UX
    - 一番良いのは、古いデバイスの鍵をLINE Serverに送る
    - ある意味マジック
    - しかし、同じ境界内でアクセスできるようになってしまう
    - Letter Sealingが侵害されてしまう
    - 受け入れられない
  - ベストセキュリティ
    - Securely Generated Passwordを入力してもらう
    - 最高のセキュリティ
    - しかし、ユーザー側が書き留めておかなければいけない
    - 入力エラーも起こりやすい
  - Denger of Low Entropy
    - 異なるパスワードが必要になる
    - コードの場合
      - 6桁は100万通りあるが
      - しかし生年月日を入れられてしまう
      - すぐに解読できる
    - パスワードも同様
      - 解読されやすい
    - 自動生成がベストだと考える
  - No encryption - Ramdomly Generated Password、色々なパターンによって良し悪しがある
- Securing Low Entropy Secrets
  - 組み合わせの鍵
  - チップ付きの銀行のカード
    - ハードウェアではあるがPIN認証が目的
    - 何回かミスったら制限される（ロックされる）
  - スマホのロック画面
    - ARM TrustZone / Apple Secure Enclab
- Hardware Enforced Security
  - PIN / Pattern / Biometric
  - Secrets Answer
- アドバンテージ
  - 完全に分離されている
    - 非常に小さく、簡単
    - 監査にも時間がかからない
  - 目的に合わせて作成されている
  - 分割された管理
    - 署名キーは独自のもの
- サーバーサイドのテクノロジー
  - 安全なハードウェアとは
    - TEE
      - CPUベースのソフトウェア
      - Intel SGX, AMD PSP, ARM TrustZone
    - TPM
      - マザボへのセキュリティチップ
    - HSM
      - Ethernet or PCE
      - セキュリティが高い
- Securing Backup With HSMs
  - Backup HSM
    - 安全な通信チャンネルを確立する必要がある
    - デバイスはエフェメラルなPublic / Private Keyを使う（使用後に使えなくなる）
  - HSM Double Encryption
    - PIN、Ephemeral Shared Keyを使用する
    - Ephemeral Shared KeyはServerも知っている
    - いくつかのプロパティがある
      - クライアントのキーはすぐに破棄される
      - クラウド側から抽出することはできない
      - カスタムコードにより、カスタムのチェックが挟める
- Programming an HSM
  - Code Signingも使う
- Security Model
  - デバイスリセットした場合はなくなる
  - シャード分割
    - 複数に分けることができる
- Last Words
  - UXとセキュリティの両立は難しい
  - LINEでも実験的に入れている、今後もユーザーが使えるようにしていく