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

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

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

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

2019年11月20日(水)・21日(木)にグランドニッコー東京 台場でLINEのデベロッパーカンファレンス「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でも実験的に入れている、今後もユーザーが使えるようにしていく

まとめ

デバイスのデータ移行って非常に難しいですよね。UXのことだけを考えたとしても、ベストを導き出すことは非常に難解です。

Letter Sealingについて全然知らなかったのですが、デバイス間のセキュアなデータ移行について詳細に理解することができました。