Share
Embed
Slide 1
Slide 1 text
Update とは何か
そして何であるべきか
チェシャ猫 (@y_taka_23)
Cloud Native Meetup Tokyo #2 (2018/06/01)
#cloudnativejp
Slide 2
Slide 2 text
gem update docker-api
#cloudnativejp
Slide 3
Slide 3 text
pip update docker-py
#cloudnativejp
Slide 4
Slide 4 text
docker pull nginx:1.14
#cloudnativejp
Slide 5
Slide 5 text
ソフトウェア更新の仕組み
● 抽象化すると単純
○ 新しいバージョンの有無を検知
○ もしあれば新バージョンをダウンロード
○ ローカルマシンへのインストール
● 通信路は TLS で保護できる
○ 通信相手の認証・暗号化・改ざん検出
○ そもそも Chrome では HTTPS がデフォルトに
#cloudnativejp
Slide 6
Slide 6 text
ご清聴ありがとうございました
Presented by チェシャ猫 (@y_taka_23)
#cloudnativejp
Slide 7
Slide 7 text
んな訳ない
#cloudnativejp
Slide 8
Slide 8 text
通信路以外にも危険が
● 更新時系列の詐称
○ 古い脆弱なバージョンをダウンロードさせる
○ 更新があるのにないかのように見せかける
● 鍵危殆化、例えば秘密鍵の流出
○ サーバやファイルの正当性が信用できなくなる
● 悪意あるサーバの挙動
○ 無限ストリームデータを送ってくるなど
#cloudnativejp
Slide 9
Slide 9 text
考えるべきことは結構多い
#cloudnativejp
Slide 10
Slide 10 text
The Update Framework
https://theupdateframework.github.io
#cloudnativejp
Slide 11
Slide 11 text
TUF プロジェクトの概要
● ソフトウェア更新のフレームワーク
○ 安全な更新を実現する
○ 何を配布するかに依存しない汎用的な仕様
○ 公式の（参照）実装は Python
● 更新の検知とダウンロードをサポート
● 実はプロジェクトとしては割と古い
○ 元になった論文は 2010 年
#cloudnativejp
Slide 12
Slide 12 text
#cloudnativejp
Slide 13
Slide 13 text
TUF の利用事例
● 既に導入されている事例
○ Docker Hub (Notary)
○ DigitalOcean
● 現在、対応が計画されている事例
○ RubyGem
○ PyPI
○ Hackage (Haskell ライブラリ)
#cloudnativejp
Slide 14
Slide 14 text
TUF レポジトリの構造
#cloudnativejp
Slide 15
Slide 15 text
TUF レポジトリの構造
#cloudnativejp
Slide 16
Slide 16 text
TUF レポジトリのメタデータ
● それぞれ別の Role として署名する
○ root : 他のメタデータ用の信頼済み鍵リスト
○ targets : 配布ファイルのサイズとハッシュ値
○ snapshot : 他のメタデータのサイズとハッシュ値
○ timestamp : snapshot のサイズとハッシュ値
● 全体として整合している必要がある
○ クライアントは timestamp で更新の有無を判断
#cloudnativejp
Slide 17
Slide 17 text
TUF レポジトリの構造
#cloudnativejp
Slide 18
Slide 18 text
TUF レポジトリのターゲット
● 実際に配布するファイルを格納
○ サイズとハッシュ値の一覧を targets.json に記録
○ デフォルトで targets.json 用の Role で署名
● 信頼の委譲 (delegation)
○ ディレクトリ構造の一部を他の Role として署名
○ ライブラリ用のレポジトリなどが典型例
○ Role の信頼関係のチェーンをメタデータに記録
#cloudnativejp
Slide 19
Slide 19 text
信頼の「閾値」の設定
● Role に対して署名鍵を複数登録
○ 署名には必ずしも全鍵を使用しなくてもよい
● 信頼に必要な鍵の最低個数を設定
○ 登録された内、その個数以上が使われていないと
正当なファイルであるとみなされない
○ 一度に複数の鍵が危殆化しない限り安全
● 閾値は Role ごとに設定できる
#cloudnativejp
Slide 20
Slide 20 text
Role の階層構造
Library-1
● file-1-1.txt
● file-1-2.txt
Library-2
● file-2-1.txt
Targets
● target.json
Root
● root.json
Snapshot
● snapshot.json
Timestamp
● timestamp.json
#cloudnativejp
Slide 21
Slide 21 text
Role による責任の分離
Library-1
● file-1-1.txt
● file-1-2.txt
Library-2
● file-2-1.txt
Targets
● target.json
Root
● root.json
Snapshot
● snapshot.json
Timestamp
● timestamp.json
#cloudnativejp
Slide 22
Slide 22 text
閾値による鍵危殆化耐性
Library-1
● file-1-1.txt
● file-1-2.txt
Library-2
● file-2-1.txt
Targets
● target.json
Root
● root.json
Snapshot
● snapshot.json
Timestamp
● timestamp.json
1 < root.threshold = 2
#cloudnativejp
Slide 23
Slide 23 text
まとめ
● ソフトウェアの更新は落とし穴が多い
○ 真面目に個別に考えようとすると大変
● TUF は安全な更新機構を提供
○ 何を配布するかに依存しない汎用フレームワーク
● 安全性を実現する二つの柱
○ 署名されたメタデータによる最新性の保証
○ 権限の分割と閾値設定による危殆化への耐性
#cloudnativejp
Slide 24
Slide 24 text
Update Your Knowledge!
Presented by チェシャ猫 (@y_taka_23)
#cloudnativejp