Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ATPの「A」
Search
yamarten
April 28, 2023
Technology
0
240
ATPの「A」
https://428lab.connpass.com/event/280610/
yamarten
April 28, 2023
Tweet
Share
More Decks by yamarten
See All by yamarten
Bluesky 2019〜2022
yamarten
1
150
PDS連合ことはじめ
yamarten
0
590
ADXが見た夢(ATPのUCANの話)
yamarten
0
270
Other Decks in Technology
See All in Technology
RubyのWebアプリケーションを50倍速くする方法 / How to Make a Ruby Web Application 50 Times Faster
hogelog
3
940
20241120_JAWS_東京_ランチタイムLT#17_AWS認定全冠の先へ
tsumita
2
290
B2B SaaSから見た最近のC#/.NETの進化
sansantech
PRO
0
870
AWS Media Services 最新サービスアップデート 2024
eijikominami
0
200
AWS Lambda のトラブルシュートをしていて思うこと
kazzpapa3
2
180
これまでの計測・開発・デプロイ方法全部見せます! / Findy ISUCON 2024-11-14
tohutohu
3
370
TanStack Routerに移行するのかい しないのかい、どっちなんだい! / Are you going to migrate to TanStack Router or not? Which one is it?
kaminashi
0
600
データプロダクトの定義からはじめる、データコントラクト駆動なデータ基盤
chanyou0311
2
330
OCI Vault 概要
oracle4engineer
PRO
0
9.7k
安心してください、日本語使えますよ―Ubuntu日本語Remix提供休止に寄せて― 2024-11-17
nobutomurata
1
1k
Python(PYNQ)がテーマのAMD主催のFPGAコンテストに参加してきた
iotengineer22
0
500
SRE×AIOpsを始めよう!GuardDutyによるお手軽脅威検出
amixedcolor
0
140
Featured
See All Featured
Visualization
eitanlees
145
15k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
840
Why Our Code Smells
bkeepers
PRO
334
57k
Adopting Sorbet at Scale
ufuk
73
9.1k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Navigating Team Friction
lara
183
14k
Making Projects Easy
brettharned
115
5.9k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
Speed Design
sergeychernyshev
25
620
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
44
2.2k
Transcript
ATPの「A」 ATPの署名の話 2023.4.28 Bluesky/ATProtocol 勉強会#1
おことわり この発表の主題は考察、というか「これ何だろうね?」 解説や紹介ではないし結論も主張も無い 現状の公式実装準拠のため、ドキュメントと矛盾する場合あり なお発表者はTypeScriptをHello World前に断念、つまり……
ATP? Authenticated: 認証された Transfer: データを送受信する Protocol: 決まりごと ちなみに: HTTP =
HyperText Transfer Protocol
Authenticated? 署名による保証を意味する(と思う) repositoryをMST(≒ハッシュ木)で 一つのハッシュにまとめて署名 コピーの改竄を検出可能 更新したら前回のCIDも含めて署名 署名はPDSが持つ秘密鍵を使う 公式PDS実装の鍵は全ユーザ同じ
何に役立つ?(憶測) ネットワークや取得側PDSに よる改竄の検出 元PDSに問い合わせ不要 BGSの検証を可能にする? 投稿側PDSの削除・改竄に対 する第三者による証明 ウェブ魚拓的に使える copy commit
@ @
署名はどう検証する? 検証されない署名に意味は無い 公式ライブラリのverifyFullHistoryを使えば検証できる com.atproto.sync.getRepoで取得したrepositoryに使えば検 証できるはず 完……とはならない
何を検証する? ちゃんと検証するなら過去commit含め repository全体があった方が良い 公式実装的にはcom.sync.getRecordで 得られる範囲で十分と考えられそう commitから対象recordへのパス以外 のCIDは展開しない それでも1record検証するためだけ にはちょっと重いかも
誰が検証する? 取得側のPDSで署名を検証するなら、 当然そのPDSは嘘を吐ける PDSは(ある程度)信頼する前提で はあるが…… とはいえクライアントで検証するの も(特にrepostとか)コスト重め 無差別に検証する訳ではなければ そんなに困らないかも @
@ record repo data? repo?
その公開鍵は本物? クライアントで検証する場合、直接DIDを 解決して公開鍵を取得する必要がある ATPで使うDIDなら誰でも解決できるはず 投稿者PDSに直接もらうのもあり DIDを管理しているPLCサーバがPDSと共謀 して嘘を吐いているかもしれない did:webの場合はユーザのコントロール 下にあるはずなので無条件に信じていい @
@ record repo repo DID pubkey PLC server PLC server
DID⇔鍵はどう検証する? DID操作もcommitのように署名している PLCサーバがoperation logとして保管 did:oydやanywiseなdid:keriに似たコンセプト 最初のoperationからDIDが導出できる 公式ライブラリのvalidateOperationLogで検証可能 operation logの取得方法は未確認
その他の問題 投稿側のPDSの暴走は防げない 署名鍵を持つため、ローテーションしか止めれらない 引越しても、どのcommitからが暴走か問題は残る PDS引越し前のスナップショットは検証できるか 現状の実装案では全commitが作り直される did:webの場合、過去の署名鍵とDIDの紐付けはどこでする?
まとめ repositoryの署名は一部検証や存在証明に使える が、本当にこれがやりたかったことか……? 他の使い途のアイディアあれば教えてください 公式にはアカウント可搬性のためっぽいが謎 ちゃんと検証するのは結構障害が多い ただし公式でも用意はしてくれているのでマシ 色々考慮は必要だし現時点で実用は厳しいかも
おまけ:署名が取得できるAPI com.atproto.syncの一部が該当 getCheckout: 指定したcommit+MST getRepo: 指定した範囲のcommit+MST getRecord: 指定したrecordまでのcommitからのpath getCommitPath: 指定した範囲のcommit(MSTを含まない)
subscribeAllRepos: 実行中の全変更(commit+MST+handle) handleの変更はrepository外(DID)の管轄だが見える
おまけ:さらにその先 DIDとrepositoryの繋がりが検証できたとして、それは本当に 「ATP外で知ってるあの人」のものなのか? did:webや一部のhandle・PDSはサーバ管理者を保証する じゃあ例えば古い名刺記載のhandleがもう他人である可能性 は?名刺の記載自体が嘘かも? 最終的にシステム外の検証はシステム外でするしかない DIDが解決しうるが、活かすには普及&did:plc拡張が必要