HSMポリシーとバリデーターのセキュリティの重要性

Loom Network Japanese

Published in

Loom Network JP

18 min readJul 25, 2019

この記事はStakeWith.Us.のMichael Ngによるゲスト投稿です。

本記事は、HSM Policies and the Importance of Validator Security(
Michael Ng) の翻訳です。万一誤訳などありましたらPrivate Note機能でお知らせ下さい。

Staking-as-a-Serviceのプロバイダーとして、StakeWith.Usはバリデーションセットアップのセキュリティを強化するセグメントについて、詳細な調査を行っている。我々はセキュリティと望ましいアップタイムのベストプラクティスが共有化されることを思い描いている — そういうわけで全てのステーキングサービスプロバイダーの高い水準を実現するため、我々が発見したことをいくつか発表していくことにした。

今回はハードウェアセキュリティモジュール(HSM)、特に物理暗号化装置であり検証設定に不可欠であるYubiHSM2にバリデーターが設定すべきポリシーの種類について触れる。

左：YubicoのWebサイトから、HSMの写真；右：指と比較して、HSMが実際どの程度の大きさか…小さいかもしれないが、かなりのパワーを持っている！

なぜHSMを使うのか？

手短にいうと、HSMは手頃な価格かつ高性能でポータブルなハードウェアであり、秘密鍵を安全に生成、保存、管理するのに役立つものだ。 HSMが適切に構成されている場合、マルウェアの攻撃とリモートでの秘密鍵の抽出ははるかに困難となる。

より詳しい情報に関しては、バリデーターがHSMを使うべき理由についてのLoom Networkの記事をチェックしよう。我々は、すべての本格的なバリデーターはHSMを利用し、物理的なサーバー上の攻撃ベクトルを最小化するべきであると考えている。HSMなしでは、priv_validator.jsonのファイルはプレーンテキストになってしまう。サーバーへのアクセスが可能となった攻撃者は、秘密鍵をコピーして：

二重支払いとしてよく知られている悪意のあるトランザクションに署名し、ステークのスラッシングや、トゥームストーンにされたおよび/または担保なしにされたデリゲーターが結果として生じ(訳者注: トゥームストーンとはバリデーターセットから排除し二度と戻れなくすること、つまりバリデーターとして葬ること。また担保無しにされるとアクティブなバリデーターセットから外れ、ブロックに署名できなくなる);
トークンがロックされ担保付けされていたとしても、攻撃者はあなたのバリデーターステークの担保を無しにすることができ、またそれが結果としてデリゲーターのステークの担保解除につながる。

HSM内の鍵の種類

デフォルトの承認方法の鍵である0x0001(デフォルトの鍵Id:0x0001、パスワード：password)はSuper-Userとして知られている。これは全てのドメインに対する全ての機能、またデリゲーションされた全ての機能を持っている — ひとつの鍵がすべてを支配すると想像して欲しい(マーベルのファンにとっては、インフィニティ・ガントレットのようなもの)。したがって、セキュリティ的過失を最小化するためにセキュアなHSMポリシーを適所に整備することが重要である。

整備が必要となる重要なポリシーのひとつは、HSMの中で鍵の能力を制限することである。我々は3つのタイプの鍵を明らかにしたが、いかなるバリデーター設定であってもこれらの鍵とインタラクトすることが必要だ:

認証鍵(Authentication key): セッションの確立、メッセージの暗号化、およびデバイス間で送受信されるメッセージのタグ付けに(アカウントのユーザー名とパスワードのように)使用される;
非対称鍵：秘密鍵+公開鍵のペア。秘密鍵のみが暗号操作の実行(すなわち署名)に使われる;
ラップ鍵：データを暗号化/解読し、非対称鍵を暗号化した状態でエクスポートするのに使われる(秘密の)鍵。

鍵の機能＋デリゲートされた機能の説明

スーパーユーザーを使用すると、特定のアクションが直接実行可能になる新しいプロパティ(新しい超能力!!)を鍵に与えることができる。例えばed25519タイプの非対称鍵に、sign-eddsaアクションを直接実行する機能「sign-eddsa」を付与することができる。

デリゲートされる機能とは、新しい鍵の生成から派生したプロパティである。例えばあなたは「put-asymmetric-key」の機能を持ったAという認証鍵を持つことができ、その鍵でデリゲートされた機能「sign-eddsa」という非対称鍵をインポートすることができるとする。これはつまり鍵Aを使用して、その鍵Aが実行できないアクションをすることができる非対称鍵Bを生成できるということだ。

すなわち鍵の有効機能とは、機能そのものとデリゲートされた機能両方に依存するということを頭に入れておかなければならない。

認証鍵は下記の一連のアクションを実行することができる：

unwrap-data ラップ鍵を使いデータを解読する
put-authentication-key HSM内に認証鍵を保存する
put-asymmetric-key デバイスに非対称鍵をインポートする

承認鍵から生成されたオブジェクトは、以下のアクションを実行することができる:

sign-eddsa: eddsa署名を実行
exportable-under-wrap: 指定されたラップ鍵と一致する暗号化データをエクスポート可能にする

秘密鍵の保護

秘密鍵の移転やバックアップを行う最もセキュアな方法は、署名の際に秘密鍵をラップしてエクスポートするやり方である。秘密鍵は３回のうち最低２回(またはn回のうちm回)はラップしなくてはならない。

ラップとは:

ランダムなシードからラップ鍵を生成し(デフォルトではaes-ccm);
ラップ鍵Aを使用して、秘密鍵をエクスポートし;
別のラップ鍵Bを使用して、その秘密鍵を再びラップする。

秘密鍵をHSMへインポートするには:

２回アンラップされる必要があり;
そうすることで、３操作のうち２つ(またはn操作のうちm)が確実に行われ;
全行程はHSM本体の中で完了する。

機能からロール(役割)を作成する

ロールを作成すべき場合とは、秘密鍵/鍵のインポート、その秘密鍵/鍵の使用やデバイスのリセット/復元などの一連の責務をカバーするのに適すると思われるときである。

有効機能及び各役割のドメインは、はっきりと設定されることが必要だ。役割が設計及び作成された際に、それらが求められている全オペレーション範囲を実行していることを確認するテストを行わなくてはならない。

先にお話ししたSuper-Userを覚えているだろうか？インフィニティ・ガントレットのように、デフォルトの承認鍵を削除して(そう、Super-Userはそれ自身を削除できる)、完全に何も邪魔やロール設定の無視をできないことを確証することが必要だ(Super-Userの削除方法については、新しい鍵の設定のセクションを参照)。

推奨されるロール

全バリデーターが持つよう我々が推奨しているロールのうち、いくつかをこちらでご紹介する。全ての実行ファイルは、0x0001を使用してログインしている間に実行される(ヒント: YubiHSM2には12のドメインがあり、１つのバリデーションプロジェクト用に１つのドメインを持つことが理論的に可能である):

Importer — 有効機能: ラップ鍵の配置、eddsa署名の実行とexportable-under-wrapの特性を持つことが可能な非対称鍵のためのデータアンラップ。Importerを生成するには、以下を実行しよう:

yubihsm> put authkey <session_id> 0x0002 importer <domain> import-wrapped,put-wrap-key,unwrap-data exportable-under-wrap,sign-eddsa,import-wrapped,unwrap-data <importer_password>

Signer — 実行機能: そのドメイン下での非対称鍵に対するeddsa署名。Signerを生成するには、以下を実行しよう:

yubihsm> put authkey <session_id> 0x0003 signer <domain> sign-eddsa sign-eddsa <signer_password>

Resetter — 実行機能: デバイスのリセット:

yubihsm> put authkey <session_id> 0x0004 resetter <domain> reset-device reset-device <resetter_password>

重要事項:

秘密鍵をエクスポートできるロールはないことに注意する。
ImporterはSignerが使う鍵を作成するが、Signerのみがトランザクションに署名できる。

新たな鍵のセットアップ

コマンドのさらなる詳細については、こちらのYubiHSM2開発者ポータルサイトを訪れてみよう。

前提条件と重要事項:

yubicohsm 2 SDKのファイルをダウンロードして解凍し;
HSMをプラグインして、‘sudo ./yubihsm-connector’でコネクターをスタートし;
デフォルトのパスワードを使用して新規セッションを作成する。全てのコマンドにはセッション番号があり、yubihsm-shell内で実行されることを覚えておこう:

yubihsm> connect
yubihsm> session open <userId> <userPassword>Example: 
yubihsm> session open 1 password

全てのsession_idは0であると仮定しよう。

以下のようにタイプすることで、あなたのデバイス内の鍵リストをチェックすることができる:

yubihsm> list objects <session_id> <key_id> <key_type>
yubihsm> list objects 0 // Returns all keys

何も記録されていないデバイスは、元々の承認鍵0x0001Aのみを持つことになる。

次に、非対称鍵を生成しよう:

yubihsm> generate asymmetric <session_id> <key_id> <label> <domain> <capabilities comma separated> <delegated_capabilities comma separated>Example:
yubihsm> generate asymmetric 0 0 key-name 3 sign-eddsa,exportable-under-wrap ed25519

公開鍵を取得するには:

yubihsm> get pubkey <session_id> <asymmetric_key_id>

ランダムなシード(秘密にそして安全に保管して、失くしてはならない)とラップ鍵(３操作のうち２つを行なっているなら、これを３回行おう)を生成しよう:

yubihsm> get random <session_id> 32
yubihsm> put wrapkey <session_id> <wrap_key_id> <label> <domains comma separated> <capabilities comma separated> <delegated capabilities comma separated> <random_seed>Example:
yubihsm> put wrapkey 0 0 NameYourWrapKey 3 export-wrapped,import-wrapped,wrap-data sign-eddsa,exportable-under-wrap <seed>

最後に３つのユニークなシードから生成されたラップ鍵３つで終了することになる。

３回のラップのうち２回を行い、(下の表に従って)暗号化された非対称鍵のエクスポートをしよう。ラップ鍵Aを２回(A + B 及び A + C)、ラップ鍵Bを１回(B + C)エクスポートするだけで良いことに気をつけてほしい:

AおよびB、Cは、３つのユニークなシードから生成された３つのユニークなラップ鍵を参照している。

yubihsm> get wrapped <session_id> <wrap_key_id> asymmetric-key <asymmetric_key_id>

これは16進数の形式で<exported_asymmetric_key_under_wrap>を返す。

ラップ鍵で再暗号化しよう。注: (A+B)を行なうので鍵Bの暗号化は１回、鍵Cについては２回暗号化すればよい(A+CとB+C):

yubihsm> encrypt aesccm <session_id> <wrap_key_id> <exported_asymmetric_key_under_wrap>

これは<double_encrypted_asymmetric_keys>を返却するはずだ。

その後、推奨ロール — ImporterとSigner、Resetterを作成してテストを行う。

必要な全範囲のオペレーションが確実に行われることを確認したら、HSMをリセットしよう。再テストしてみて満足いく結果であれば、以下のコマンドでSuper-Userを削除しよう(承認鍵0x0001でログイン中に):

yubihsm> delete <session> 0x0001 authentication-key

別のHSMへの鍵の再インポート/インポート

使用した後毎回HSMのリセットを行うとすると、Importerの承認鍵を作成しなくてはならない:

yubihsm> session open 0x0001 passwordyubihsm> put authkey <session_id> 0x0002 importer <domain> import-wrapped,put-wrap-key,unwrap-data exportable-under-wrap,sign-eddsa,import-wrapped,unwrap-data <importer_password>

Importerでログインして、ラップ鍵をHSMに配置してみよう。どのラップ鍵を使用しているかに従って、合計３つのロック解除条件がある(この場合はA + B)。最初は常に、外側のレイヤーから解読することになる:

yubihsm> session open 0x0002 <importer_password>yubihsm> put wrapkey <session_id> 0x000b wrapkey_B <domain> unwrap-data,import-wrapped exportable-under-wrap,sign-eddsa <seed_B>

これは<wrap_key_id>を返すはずだ。下記を解読して、<outer_wrapped_validator_key>を取得しよう。これは２つ目のラップ鍵を取得した後に使用される:

yubihsm> decrypt aesccm <session_id> <wrap_key_id> <double_encrypted_asymmetric_keys A + B>

２つ目のラップ鍵をHSMへ再び配置し、<inner_wrap_key_id>を取得しよう:

yubihsm> put wrapkey <session_id> 0x000a wrapkey_A <domain> import-wrapped,unwrap-data exportable-under-wrap,sign-eddsa <seed A>

このコマンドを使用して、バリデーターキーをHSMへとインポートしよう:

yubihsm> put wrapped <session_id> <inner_wrap_key_id> <outer_wrapped_validator_key>

‘Object imported as 0x0000’ of type asymmetric-key’で始まるメッセージを受け取るはずだが、そうしたらあなたのバリデーターキーはHSMに保存されている。

署名鍵/署名データの検証

Signerと非対称鍵をテストするには、あなたのsigner承認鍵 0x0003でログインしよう:

yubihsm> session open 0x0003 <signer_password>

このコマンドを実行して署名しよう:

yubihsm> sign eddsa <session_id> <assymmetric_key_id> ed25519 <message>

HSMのリセット

承認鍵を失くした場合、物理的にHSMをリセットすることができる(HSMを差し込んで10秒間ボタンを押す)。もしくはこちらのコマンドラインでも可能だ:

yubihsm> reset <session_id>

その後HSMをチェックして、完全にリセットされていることを確認しよう:

yubihsm> list objects <session_id> <domain>

警告: デバイスをリセットすると、全ての認証鍵、ラップ鍵、非対称鍵がデバイスから削除され復元できなくなる。HSMを再使用するには、物理的に取り外して再起動しなくてはならないため、前もってそのつもりでいること。リセットされたHSMは、Super-Userの全権限に併せてデフォルトのユーザー名とパスワード(1: パスワード)を持つ。

終わりに

バリデーターがHSMポリシーのセットアップを行ったり、デリゲーターがバリデーションセットアップにおけるHSMの重要性を理解したりする際、この記事が役立つことを我々は望んでいる。デリゲーションすると自らで管理する必要はあないが、ネットワーク保護に付随するスラッシングやセキュリティのリスクがあるということで、デリゲーターは自らが選んだバリデーターが安全で高度に利用可能なセットアップを行っていると信頼しなくてはならない。

StakeWith.Usチームは、詳細な調査および幅広いコミュニティとの発見の共有を継続していく。またLoom NetworkやCosmos Networkといった高クオリティなブロックチェーンネットワークのブートストラップも続けていく— 今後デリゲーターになるかもしれない皆さんへ: 私たちにぜひステーキングを！

既存のデリゲーターの皆さんへ — これまでご支援いただきありがとう。この旅路に参加してくださっていることに感謝を申し上げたい！

ではまた次回！

さよなら！

免責事項: この記事は、一般的情報とHSMの機能についての理解を得るため、教育目的のみに利用できるよう作成されています。Yubicoから提供されるオンラインドキュメントを常にチェックするようにしてください。このガイドの使用にあたり、全てのアクションとHSMの設定や使用で生じる損害については、あなたの自己責任となります。

MW Partnersは初期ステージの投資会社であり、ブロックチェーンプロジェクトにフォーカスしている。MW PartnersをTwitterでフォローしよう。

StakeWith.Usは、ブロックチェーンのリーディングプロジェクト向けのセキュアなStaking-as-a-Serviceプロバイダである。あなたの暗号通貨を有効活用してみよう — 手間はかからない。

我々は現在、誰もが無料で使えるLoom Network用のシンプルなダッシュボードを準備している。

バリデーションのアップデート情報を受け取りたいなら、StakeWith.Usを Twitter、Telegram、Mediumでフォローしよう。さらにWeChatグループにご興味があれば、gobigordietryingまたはmcry89でご参加いただける。

それか以下のような場合は、メールアドレスEarn@StakeWith.Usまでご連絡をお待ちしている:

どうしても我々に聞きたいことがある;
あなたのプロジェクトがプロフェッショナルなバリデーターを探している;
StakeWith.Usとの投資及びパートナーシップの機会を検討している。

HSMに関する調査を行い、この記事のドラフトを一緒に作成してくれたOliver Weeに感謝を述べたい！

Loom Networkは、イーサリアムのハイスケーラブルなDPoSサイドチェーン構築のためのプラットフォームで、大規模ゲームやソーシャルアプリにフォーカスしています。さらなる情報は こちらから.

LOOMトークンをステークして、PlasmaChainのセキュリティ維持に参加しませんか？ やり方はこちら

そしてもしこの記事をお楽しみいただけ、最新情報の受け取りをご希望であれば、私たちのプライベートメーリングリストへの登録や、Telegram、Twitter、GithubやQiitaのフォローをお願いします！