署名および暗号化されたデータを IPFS に保存する方法

署名および暗号化されたデータを IPFS に保存する方法

認証され暗号化されたデータを IPFS に保存することは、多くの Web3 アプリケーションの中心的な構成要素ですが、これまでのところ、このタイプのデータをエンコードするための標準化された方法はありませんでした。

標準がなかったため、多くの開発者は署名および暗号化されたデータ用にカスタム形式を作成せざるを得ませんでした。データを IPFS の特定の実装に保存することにより、IPFS に保存された情報のオープン性と相互運用性が妨げられていました。データを検証する別の方法は、データを IPFS に格納し、データの CID を Ethereum などのブロックチェーン上のスマート コントラクトに格納することです。本質的には、データに署名を追加し、ブロックチェーン上に署名の記録を保持するコストのかかる方法です。

EIP-2844 の導入により、ウォレットが DID と dag-joseIPLD コーデックに基づいてデータの署名と復号化を行う新しい方法をサポートできる標準が実現し、認証および暗号化されたデータを IPFS に直接置くことができるようになりました。

DID と JOSE とは何ですか?

DID は、分散識別子の W3C 標準です。

詳細については、前回の記事「Astral が新しい世界を構築」を参照してください。簡潔にするために、DID では、文字列識別子 (例: did:3:bafy...) から署名検証と鍵交換のための公開鍵を含む DID ドキュメントに変換するための一般的な方法を指定します。ほとんどの DID アプローチでは、セキュリティ上の理由からキーがローテーションされるときにドキュメントを更新できます。

JOSE は IETF (Internet Engineering Task Force) の標準であり、JSON Object Signature and Encryption の略称です。その意味はほぼこれで説明できますこの標準には、JWS (JSON Web 署名) と JWE (JSON Web 暗号化) という 2 つの主要なプリミティブがあります。どちらの形式でも複数の参加者が許可されます。JWS ではペイロードに 1 つ以上の署名が存在する可能性があり、JWE では暗号化されたプレーンテキストの受信者が 1 人以上存在する可能性があります。

dag-jose と EIP2844 を使った構築

基本的な構成要素として dag-jose と EIP-2844 を使用して Ceramic を構築した際に、これらのテクノロジをより簡単に使用できるようにする低レベルのツールを作成しました。

js-3id-did-provider は、3ID を DID メソッドとして使用する EIP-2844 の実装です。単独で DID プロバイダーとして使用することも、3ID Connect ライブラリ内でより便利に使用することもできます。 3ID Connect を使用すると、ユーザーは Ethereum ウォレットを使用して DID プロバイダーにアクセスできます (他のブロックチェーンのサポートも近日中に開始されます)。

key-did-provider-ed25519 は、Key DID メソッドを使用した EIP-2844 の実装です。これは、署名と暗号化の両方をサポートする最もシンプルな DID プロバイダーです。

js-did は、開発者がユーザーを DID の形式で表現できるようにするライブラリです。これは、このチュートリアルで取り上げるメイン インターフェースです。これにより、現在認証されているユーザーでデータに署名したり、任意のユーザー (DID) に対してデータを暗号化したり、現在認証されているユーザーでデータを復号化したりできるようになります。

IPFSの署名データ

dag-jose IPLD コーデックを使用すると、リンクされ署名されたデータ構造を作成できます。これは、他のデータへのリンクを含む JSON Web 署名 (JWS) を作成することによって行われます。 dag-jose コーデックが解決する主な問題の 1 つは、JWS ペイロードが従来 base64url としてエンコードされていることです。つまり、IPLD リンクが含まれている場合、それらを通過することはできません。

代わりに、DagJWS では、ペイロードを CID のバイトに強制します。次に、コーデックはペイロードを CID インスタンスに変換し、それを DagJWS のリンク プロパティとして設定します。これにより、結果の DAG を簡単に走査できるようになります。

dag-jose サポートによる IPFS の設定

dag-jose は新しい IPLD コーデックであるため、js-ipfs にはまだデフォルトで含まれていません。また、js-ipfs がまだサポートしていない新しい IPLD コーデック API も実装しています。したがって、IPFS インスタンスを作成するときは、次の操作を行う必要があります。

'ipfs' から IPFS をインポートします。 'dag-jose' から dagJose をインポートします。 'multiformats/basics' から multiformats をインポートします。 'multiformats/legacy' から legacy をインポートします。 multiformats.multicodec.add(dagJose) const dagJoseFormat = legacy(multiformats, dagJose.name) const ipfs = await Ipfs.create({ ipld: { formats: [dagJoseFormat] } })

正しいマルチフォーマットバージョンがインストールされていることを確認してください。

$ npm i マルチフォーマット@3.0.3
DIDインスタンスの設定

以下の設定例では、key-did-provider-ed25519 を使用します。上記のネットワークを使用することを選択した場合、バックグラウンドで 3ID Connect と js-3id-did-provider が使用されます。

import { DID } from 'dids'import { Ed25519Provider } from 'key-did-provider-ed25519'import KeyResolver from '@ceramicnetwork/key-did-resolver'import { randomBytes } from '@stablelib/random'// DID のシークレットとして使用されるシードを生成const seed = randomBytes(32)// did インスタンスを作成const provider = new Ed25519Provider(seed)const did = new DID({ provider,resolver: KeyResolver.getResolver() })await did.authenticate()window.did = didconsole.log('DID に接続しました:', did.id)
署名付きデータ構造を作成する

これで、IPFS への署名とデータの追加を開始できます。まず、ペイロードを受け入れ、did.createDagJWS メソッドを使用して署名し、結果のデータを IPFS に追加する簡単な関数を作成しましょう。

以下のコードからわかるように、このメソッドからは、jwsDagJWS 自体と linkedBlock でエンコードされたペイロードの生のバイトの 2 つのオブジェクトが取得されます。バックグラウンドでは、ペイロードが dag-cbor を使用してエンコードされ、その後、エンコードされたペイロードの CID が作成された jws のペイロードとして使用されます。 jws.link を介して DagJWS インスタンス上のペイロード CID にアクセスできます。

async function addSignedObject(payload) { // ペイロードを dag-jose として署名します const { jws, linkedBlock } = await did.createDagJWS(payload) // JWS を ipfs dag に配置します const jwsCid = await ipfs.dag.put(jws, { format: 'dag-jose', hashAlg: 'sha2-256' }) // ペイロードを ipfs dag に配置します await ipfs.block.put(linkedBlock, { cid: jws.link }) return jwsCid}

この関数を使用して、最初の署名付きデータ オブジェクトを作成しましょう。

// 最初の署名済みオブジェクトを作成しますconst cid1 = await addSignedObject({ hello: 'world' })// DagJWS をログに記録します:console.log((await ipfs.dag.get(cid1)).value)// >{// > payload: "AXESIHhRlyKdyLsRUpRdpY4jSPfiee7e0GzCynNtDoeYWLUB",// > signatures: [{// > signature: "h7bHmTaBGza_QlFRI9LBfgB3Nw0m7hLzwMm4nLvcR3n9sHKRoCrY0soWnDbmuG7jfVgx4rYkjJohDuMNgbTpEQ",// > protected: ], // > link: CID(bafyreidykglsfhoixmivffc5uwhcgshx4j465xwqntbmu43nb2dzqwfvae)// > }// ペイロードをログに記録:ipfs.dag.get(cid1, { path: '/link' }).then(b => dag.get(cid2, { path: '/link/prev/link' }).then(b => console.log(b.value))// > { // > hello: 'getting the hang of this'// > prev: CID(bagcqcerappi42sb4uyrjkhhakqvkiaibkl4pfnwpyt53xkmsbkns4y33ljzq)// > }// 古いペイロードをログに記録:ipfs.dag.get(cid2, { path: '/link/prev/link' }).then(b => console.log(b.value))// > { // > hello: '慣れてきました'// > prev: CID(bagcqcerappi42sb4uyrjkhhakqvkiaibkl4pfnwpyt53xkmsbkns4y33ljzq)// > } > { hello: 'world' }

ペイロードは DID によって署名されるため、CID と JWS の値は異なることに注意してください。

署名検証のためのデータ構造

JWS の検証は非常に簡単です。 JWS オブジェクトを取得して、verifyJWS メソッドに渡すだけです。署名が無効な場合、この関数はエラーをスローします。署名が有効な場合は、JWS の署名に使用された DID (キー フラグメントを含む) を返します。

const jws1 = ipfs.dag.get(cid1) を待機しますconst jws2 = ipfs.dag.get(cid2) を待機しますconst signingDID1 = did.verifyJWS(jws1) を待機しますdid.verifyJWS(jws2)
IPFS で暗号化されたデータ

IPFS でデータに署名するのは難しい問題ですが、おそらくもっと興味深いのはデータの暗号化です。 dag-jose と EIP-2844 を使用すると、データを 1 つ以上の DID に暗号化し、IPFS に直接保存できます。以下では、js-did ライブラリが提供する便利なツールを使用してこれを行う方法を示します。

IPLDデータの暗号化

1 つ以上の DID に暗号化された DagJWE オブジェクトを作成する簡単な方法があります。createDagJWE。このメソッドは、IPLD オブジェクト (CID リンクの JSON オブジェクトも含まれる場合があります) と DID の配列を受け入れます。

DID を解決して、DID ドキュメント内にある公開暗号化キーを取得し、それらのキーで暗号化された JWE を作成します。まず、JWE を作成して IPFS に配置するヘルパー関数を作成しましょう。

非同期関数 addEncryptedObject(cleartext, dids) { const jwe = await did.createDagJWE(cleartext, dids) return ipfs.dag.put(jwe, { format: 'dag-jose', hashAlg: 'sha2-256' })}

この機能があれば、暗号化されたオブジェクトをいくつか作成できます。次の例では、最初に単純な暗号化オブジェクトを作成し、次に前のオブジェクトにリンクされた追加の暗号化オブジェクトを作成します。

const cid3 = await addEncryptedObject({ hello: 'secret' }, [did.id]) const cid4 = await addEncryptedObject({ hello: 'cool!', prev: cid3 }, [did.id])

上記の例では、[did.id](を使用していることに注意してください。 ) は、データを現在検証されている DID に暗号化します。もちろん、ローカルで認証されていないユーザー (別のユーザーなど) の DID にデータを暗号化することもできます。

IPLDデータの復号化

IPFS からデータを取得した後、暗号化された JWE のみが取得されます。つまり、データを取得した後でそれを復号化する必要があるということです。相互にリンクされたオブジェクトはすでに作成されているので、これらのオブジェクトを取得して再帰的に復号化する関数を作成しましょう。

非同期関数 followSecretPath(cid) { const jwe = (await ipfs.dag.get(cid)).value const cleartext = await did.decryptDagJWE(jwe) console.log(cleartext) if (cleartext.prev) { followSecretPath(cleartext.prev) }}

上記の関数は例であり、復号化されたオブジェクトのみをログに記録します。これを使用して、これらのオブジェクトの内容を表示できます。

// 単一のオブジェクトを取得しますfollowSecretPath(cid3)// > { hello: 'secret' }// 複数のリンクされたオブジェクトを取得しますfollowSecretPath(cid4)// > { hello: 'cool!', path: CID(bagcqceraqittnizulygv6qldqgezp3siy2o5vpg66n7wms3vhffvyc7pu7ba) }// > { hello: 'secret' }

<<:  イーサリアムネットワークの1日の取引量はビットコインより28%高い

>>:  2021 年の Polkadot エコシステムの価値は何ですか? |オンライン教室

推薦する

オーストラリア郵便局、アイデンティティ問題の解決にブロックチェーン技術の活用を発表

オーストラリア証券取引所がブロックチェーン技術の開発と応用に着手したことに続き、別のオーストラリアの...

鉱山会社は強気ですか?ビットコインの採掘難易度が3ヶ月で最大の増加を記録

マイナーからのビットコインの平均流出量は減少し続けています。 BTC.comのデータによると、ビット...

バリュー投資は死んだが、MEMEは永遠に生き続けるのか?

BOME と SLERF は狂気じみた上昇を終え、市場は再び富を得るための「ゴールドラッシュ」を経...

暗号通貨界の大物が10億ドル規模の上場企業を報告:同社の最新の反応はここに

8月8日午後、易邦インターナショナルは記者会見を開いた。同社の胡東会長は、先週金曜日(8月6日)、浙...

上海のアップグレードは間近に迫っています。 ETHステーキングのメリットを科学的に得るにはどうすればいいですか?

上海の格上げが迫る中、流動性担保トラックが注目されている。上海アップグレード後、アンステークが有効に...

Innosilicon: Sia ハードフォークに関する公式声明

Innosiliconの公式WeChatアカウントは声明を発表した。 Siaハードフォークに関するI...

Uniswap NFT マーケット プロトコルの解明: 単なるアグリゲーター以上のもの

今回、Uniswap はアグリゲーター プラットフォームとスケジューリング プロトコルをリリースした...

コーネル大学教授がEOSの中央集権化の欠陥を批判

著名な暗号通貨専門家でコーネル大学教授のシラー氏は最近、EOSの状況は悪化すると指摘し、EOSが提案...

データ:過去24時間で破壊されたETHの数は10,000を超え、新記録を樹立

8月31日午前10時30分、Ultrasound.moneyのデータによると、過去24時間でイーサリ...

ロシアの教会は仮想通貨マイニングのために高額の電気代を支払うことになる

Bitcoin.comによると、最近の法的判決により、ロシアのイルクーツクにある教会は、敷地内にマイ...

標準ハッシュレートトークン SFIL: Filecoin マイニングを簡単にする

2020年10月15日のメインネットの正式リリース以来、Filecoinマイニングの「暗黒時代」は...

暗号通貨の世界のマイナーリズム

こうすることで、スマート コントラクトを小さく保つインセンティブが生まれ、コストが削減されます。コン...

Grin V4.0 ハードフォーク計画: メインネットアップグレードは 7 月 15 日に実施予定

出典: ファーストクラス・ウェアハウス編集者注: 元のタイトルは「Grin v4.0 ハードフォーク...