ut
2024年4月23日 16時09分
<背景>
AWS IoT Greengrass V2 を動作させようとする場合、AWS が提供する PKCS#11 プロバイダ (aws.greengrass.crypto.Pkcs11Provider) コンポーネントにより、使用する HSM に対して以下のような要件があります:
・プライベートキーと証明書は HSM の同じスロットに保存する必要があり、HSM がオブジェクト ID をサポートしている場合、同じオブジェクトラベルとオブジェクト ID を使用する必要があります。
(以上 https://docs.aws.amazon.com/ja_jp/greengrass/v2/developerguide/hardware… および https://docs.aws.amazon.com/ja_jp/greengrass/v2/developerguide/pkcs11-p… より転記)
既存の証明書と鍵は上記条件に当てはまらないためか、Greengrass 起動時に "Private key and certificate labels must be the same" のエラーログが生じ AWS IoT との接続を確立することできませんでした。念のため AWS IoT が発行する証明書および秘密鍵をそれぞれ se05x_setkey にて SE050 に格納した場合も、証明書と秘密鍵とで異なるオブジェクトラベルとオブジェクト ID とならざるを得ない (同じ ID 指定では警告が出て fail する) ためか、同様のエラーにて接続することができませんでした。
<質問>
HSM に対する知識が乏しいため教えていただきたいのですが、そもそも A6E で用いられている SE050 では AWS が提供する PKCS#11 プロバイダコンポーネントが示すような設定方法 (同じオブジェクトラベルとオブジェクト ID を使用してプライベートキーと証明書を保存) に対応しているのでしょうか。もしそうであれば具体的な設定コマンドをご教示いただきたくお願いいたします。
コメント
ut
2024年4月24日 9時32分
アットマークテクノ 古賀様
早速のご返信、誠にありがとうございます。
NXP 社の MW については未確認でしたので今後確認の上、試してみようと思います。
以下、いただいた確認内容に関する回答です:
> Q1: 「既存の証明書と鍵」とおっしゃっているのは、何を指しているでしょうか？
> 以下の Howto で説明している証明書と、リファレンスキーのことでしょうか：
はい。それらをたとえば "pkcs11:object=sss:110100F0;type=cert" のような PKCS #11 URI 形式で Greengrass の設定ファイル中の system.certificateFilePath と system.privateKeyPath に指定する方式を試しておりました。
その他、両者を取り出してファイルシステム上に配置しておく方式 (見た目上一般的な Greengrass のインストールが行われた状態と同様になる) も試みましたが、こちらの場合は OPENSSL_CONF や EX_SSS_BOOT_SSS_PORT といった環境変数を介した参照が生じないのか SE050 へのアクセスが行われた形跡を見つけることができず、また結果として AWS との間に TLS セッションを確立するには至りませんでした。もう少し時間が確保できたらこちらの方も追ってみたいとは考えています。
> Q2: Greengrass Core v2 は、Debian ベースのコンテナ内で動作させていらっしゃるという認識で、合っているでしょうか？
はい、そのご認識の通りです。
at_shinya.koga
2024年4月24日 10時30分
アットマークテクノの古賀です。
utさん；
>早速のご返信、誠にありがとうございます。
>NXP 社の MW については未確認でしたので今後確認の上、試してみようと思います。
お手数をかけまして恐縮ですが、どうぞ宜しくお願いします。
>以下、いただいた確認内容に関する回答です:
有難うございます。順にコメントします。
>>Q1: 「既存の証明書と鍵」とおっしゃっているのは、何を指しているでしょうか？
>> 以下の Howto で説明している証明書と、リファレンスキーのことでしょうか：
>
>はい。それらをたとえば "pkcs11:object=sss:110100F0;type=cert" のような PKCS #11 URI 形式で Greengrass の設定ファイル中の system.certificateFilePath と system.privateKeyPath に指定する方式を試しておりました。
了解しました。
SE050 Plug&Trust MW のアーカイブに収録されている Greengrass 用の README では、sscli set xx pair コマンドを使って SE050 にプロビジョニングする際、'sss:' の形式によりラベルと ID を指定する手順が説明されています。
SE050 へのプロビジョニング後、certificateFielPath と privateKeyPath の設定値を変更する手順になっていますが、privateKeyPath に設定する URI では、type=private にしていますね。
なお、先のコメントで「プライベートキーを内部生成」と書きましたが、README を読み直したところ、プライベートキーと証明書を SE050 外部からプロビジョニングする手順になっているようです。ごめんなさい。
>その他、両者を取り出してファイルシステム上に配置しておく方式 (見た目上一般的な Greengrass のインストールが行われた状態と同様になる) も試みましたが、こちらの場合は OPENSSL_CONF や EX_SSS_BOOT_SSS_PORT といった環境変数を介した参照が生じないのか SE050 へのアクセスが行われた形跡を見つけることができず、また結果として AWS との間に TLS セッションを確立するには至りませんでした。もう少し時間が確保できたらこちらの方も追ってみたいとは考えています。
そうですね。上記 README を見ると、これらの環境変数による設定を使用するのは、greengrassd に対してではなく、OTA アップデートの場合になっています。
>>Q2: Greengrass Core v2 は、Debian ベースのコンテナ内で動作させていらっしゃるという認識で、合っているでしょうか？
>
>はい、そのご認識の通りです。
了解しました。追加で確認ですが、Greengrass Core と同時に Armadillo Twin をご利用になるでしょうか？
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
https://manual.armadillo-twin.com/make-available/
もし Armadillo Twin をご利用になる場合は、Armadillo 上で動作する Armadillo Twin のエージェントが SE050 を使用するため、Greengrass Core との間で SE050 のアクセスが競合してしまい、一方または両方がエラーしてしまう可能性が高いです。
弊社からリリースしております、ビルド済みの SE050 Plug&Trust MW パッケージでは、Armadillo Twin のエージェントと、SE050 を使用するコンテナアプリケーションとの間での、SE050 アクセス競合を回避するための変更を加えています。
Greengrass Core で SE050 をご利用される際、Armadillo Twin もご利用になる場合は、アクセス競合回避の対応が必要になります。その場合は、お知らせください。
ut
2024年4月24日 22時35分
アットマークテクノ 古賀様
お世話になっております。
ご紹介いただいた貴社 Howto 記事とはバージョンは異なる (04.05.01) ものの MW を入手し、Armadillo 上で ssscli コマンドを利用可能な状態にしました。実装されているコマンド群の詳細を不足のドキュメント等を通じて確認しておりますが、要件である「・プライベートキーと証明書は HSM の同じスロットに保存する必要があり、HSM がオブジェクト ID をサポートしている場合、同じオブジェクトラベルとオブジェクト ID を使用する必要があります。」を実現するための方法が不明な状況です。
基本的なコマンドである ssscli set rsa pair 0x00000010 privateKey.der は期待通りに成功しますが、PKCS#11 のオブジェクトラベルとしては "sss:" + "指定した ID (リトルエンディアン)" である sss:10000000 が自動的に付与され、そのラベルを変更する方法は見つけられておりません。そこで「同じオブジェクト ID」となることを期待して証明書を同 ID にて inject しようとすると ”Object id 0x10 exists” となって書き込めず、結局のところ「同じオブジェクトラベルとオブジェクト ID を使用」という状況を作り出すことができておりません (参考までに実行した内容を示すコメント付きのログファイルを添付いたします)。
つきましては当初の目的であるプライベートキーと証明書を「同じオブジェクトラベルと ID」で登録するために必要なコマンド群をご教示いただきたく、お忙しいところ恐縮ですが何卒お願い申し上げます。
| ファイル | ファイルの説明 |
|---|---|
| log.txt |
at_shinya.koga
2024年4月25日 5時43分
アットマークテクノの古賀です。
utさん：
>ご紹介いただいた貴社 Howto 記事とはバージョンは異なる (04.05.01) ものの MW を入手し、
>Armadillo 上で ssscli コマンドを利用可能な状態にしました。
僕も 04.05.01 を見て先のコメントを書きました。
>実装されているコマンド群の詳細を不足のドキュメント等を通じて確認しておりますが、
>要件である「・プライベートキーと証明書は HSM の同じスロットに保存する必要があり、
>HSM がオブジェクト ID をサポートしている場合、同じオブジェクトラベルと
>オブジェクト ID を使用する必要があります。」を実現するための方法が不明な状況です。
>
>基本的なコマンドである
>ssscli set rsa pair 0x00000010 privateKey.derは期待通りに成功しますが、
>PKCS#11 のオブジェクトラベルとしては "sss:" + "指定した ID (リトルエンディアン)" である
>sss:10000000が自動的に付与され、そのラベルを変更する方法は
>見つけられておりません。
SE050 Plug&Trust MW のアーカイブに収録されている Greengrass 用の README の当該箇所には、ssscli xxx pari コマンドに渡す keyID にラベルを付けろという注意書きがありますよね。
つまり、
ssscli set rsa pair 0x00000010 privateKey.der
ではなく
ssscli set rsa pair sss:0x00000010 privateKey.der
としろというように書いてありますが、こうした場合は、どうなるでしょうか？
ut
2024年4月25日 8時48分
アットマークテクノ 古賀様
お世話になっております。
> SE050 Plug&Trust MW のアーカイブに収録されている Greengrass 用の README の当該箇所には、ssscli xxx pari コマンドに渡す keyID にラベルを付けろという注意書きがありますよね。
> つまり、
> ssscli set rsa pair 0x00000010 privateKey.der
> ではなく
> ssscli set rsa pair sss:0x00000010 privateKey.der
> としろというように書いてありますが、こうした場合は、どうなるでしょうか？
下記のような Type エラーになります:
# ssscli set rsa pair sss:0x00000010 private.der
ssse-flw: EmbSe_Init(): Entry
App :INFO :Using PortName='/dev/i2c-1:0x48' (ENV: EX_SSS_BOOT_SSS_PORT=/dev/i2c-1:0x48)
sss :INFO :atr (Len=35)
00 A0 00 00 03 96 04 03 E8 00 FE 02 0B 03 E8 08
01 00 00 00 00 64 00 00 0A 4A 43 4F 50 34 20 41
54 50 4F
sss :WARN :Communication channel is Plain.
sss :WARN :!!!Not recommended for production use.!!!
ssse-flw: Version: 1.0.5
ssse-flw: EmbSe_Init(): Exit
ssse-flw: Control Command EMBSE_LOG_LEVEL; requested log level = 4
ERROR:cli.cli:invalid literal for int() with base 16: 'sss:0x00000010'
ERROR:cli.cli:'Context' object has no attribute 'session'
Traceback (most recent call last):
File "/usr/local/bin/ssscli", line 33, in <module>
sys.exit(load_entry_point('ssscli', 'console_scripts', 'ssscli')())
File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1157, in __call__
return self.main(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1078, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1688, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1688, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1688, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1434, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 783, in invoke
return __callback(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/click/decorators.py", line 92, in new_func
return ctx.invoke(f, obj, *args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 783, in invoke
return __callback(*args, **kwargs)
File "/root/se05x_mw_v04.05.01/simw-top/pycli/src/cli/cli_set.py", line 373, in pair
cli_ctx.log("ERROR! Could not Inject RSA Pair at KeyID 0x%08X "
TypeError: %X format: an integer is required, not strご指摘の simw-top/demos/linux/green_grass/Readme.rst 内の記述は、記載されている ssscli set ecc pair 0x20181001 <path-to-core-keypair> コマンドを実行した場合、PKCS11 オブジェクトラベルとしては sss: が付与されて sss:0101820 となることに言及しているだけと理解しておりましたが、本来期待される動作とは異なっているのでしょうか。
貴社検証環境においては上記内容を含めて正常に動作するということであれば、こちらの環境の問題としてあらためて確認させていただきますので、引き続きどうぞよろしくお願いいたします。
at_shinya.koga
2024年4月25日 9時51分
アットマークテクノの古賀です。
utさん：
>>SE050 Plug&Trust MW のアーカイブに収録されている Greengrass 用の README の
>>当該箇所には、ssscli xxx pari コマンドに渡す keyID にラベルを付けろという
>>注意書きがありますよね。
>>つまり、
>> ssscli set rsa pair 0x00000010 privateKey.der
>>ではなく
>> ssscli set rsa pair sss:0x00000010 privateKey.der
>>としろというように書いてありますが、こうした場合は、どうなるでしょうか？
>
>下記のような Type エラーになります:
>
# ssscli set rsa pair sss:0x00000010 private.der ...
件の README を見ると、keuID 単体を16進形式で与える場合とは違い、ラベル付きで与える場合は、リトルエンディアンにしたうえでラベル 'sss' を付けた形式にしろと書いてありますよね。昨晩書いていらしたコメントをちゃんと読んでいませんでしたが、
utさん（2024年4月24日 22時35分）：
>そこで「同じオブジェクト ID」となることを期待して証明書を同 ID にて inject
>しようとすると ”Object id 0x10 exists” となって書き込めず…
と書いていらっしゃいましたね。ごめんなさい。
"”Object id 0x10 exists" のエラーが出るのは、既にその ID でプロビジョニング済みだからだと思いますので、違う keyID でプロビジョニングするか、その keyID を一旦削除してからプロビジョニングする必要があるのかも知れません。
>貴社検証環境においては上記内容を含めて正常に動作するということであれば、
>こちらの環境の問題としてあらためて確認させていただきますので、引き続き
>どうぞよろしくお願いいたします。
最初に書きましたように、弊社では Greengrass で SE050 を使ったことがありませんので、この手順に関して検証していません。ごめんなさい。
ut
2024年4月25日 10時49分
アットマークテクノ 古賀様
> 件の README を見ると、keuID 単体を16進形式で与える場合とは違い、ラベル付きで与える場合は、リトルエンディアンにしたうえでラベル 'sss' を付けた形式にしろと書いてありますよね。昨晩書いていらしたコメントをちゃんと読んでいませんでしたが、
すみませんが記載いただいた内容がよく理解できませんので、認識に齟齬がないよう具体的なコマンドにて例示していただけますでしょうか。
なおエンディアンの記載方法について言えば「keyid は 1 から 0x7BFFFFFF の範囲 が利用者に開放されています」と貴社ドキュメント (Armadillo-IoT ゲートウェイ G4 セキュリティガイド) に記載されておりますことから、例え解釈が 0x10000000 と 0x00000010 のどちらになったとしても利用可能範囲内であり、実際エンディアンを変えて入力してもエラー内容に変化はありません (エラー内容としては数値が期待されているところに文字列を入力していることを示しているのでなるべくしてなっていると理解してます) 。
> 最初に書きましたように、弊社では Greengrass で SE050 を使ったことがありませんので、この手順に関して検証していません。ごめんなさい。
当初から Greengrass での挙動はあくまで背景であり、当方が確認したい内容は、その要件部分に記載されていることが SE050 で実現できるかどうかという点のみです。
以上よろしくご確認ください。
at_shinya.koga
2024年4月25日 10時54分
アットマークテクノの古賀です。
utさん：
>>件の README を見ると、keuID 単体を16進形式で与える場合とは違い、ラベル付きで与える場合は、リトルエンディアンにしたうえでラベル 'sss' を付けた形式にしろと書いてありますよね。昨晩書いていらしたコメントをちゃんと読んでいませんでしたが、
>
>すみませんが記載いただいた内容がよく理解できませんので、認識に齟齬がないよう具体的なコマンドにて例示していただけますでしょうか。
件の README の記載を見てください、というのが回答です。
>>最初に書きましたように、弊社では Greengrass で SE050 を使ったことがありませんので、この手順に関して検証していません。ごめんなさい。
>
>当初から Greengrass での挙動はあくまで背景であり、当方が確認したい内容は、その要件部分に記載されていることが SE050 で実現できるかどうかという点のみです。
現時点では、僕は分からないです。ごめんなさい。
at_shinya.koga
2024年5月2日 15時12分
アットマークテクノの古賀です。
古賀（2024年4月25日 9時51分）：
>"”Object id 0x10 exists" のエラーが出るのは、既にその ID でプロビジョニング
>済みだからだと思いますので、違う keyID でプロビジョニングするか、その keyID を
>一旦削除してからプロビジョニングする必要があるのかも知れません。
sscli のコマンドリファレンスが
simw-top/doc/pycli/doc/cli_commands_list.html
に記載されていますが、プロビジョニングした鍵の削除（erase）は、
ssscli erase [OPTIONS] keyid
で出来ると書かれています。
こちらでは、まだ確認していませんが、ssscli erase 0x00000010 で 削除してから、
再度
ssscli set rsa pair sss:10000000 privateKey.der
を実行すると、どうなるでしょうか？
at_shinya.koga
2024年4月24日 7時38分
アットマークテクノの古賀です。
utさん：
><質問>
>HSM に対する知識が乏しいため教えていただきたいのですが、そもそも A6E で用いられている SE050 では AWS が提供する PKCS#11 プロバイダコンポーネントが示すような設定方法 (同じオブジェクトラベルとオブジェクト ID を使用してプライベートキーと証明書を保存) に対応しているのでしょうか。
はい。ただし、ユーザーが作成したプライベートキーと証明書を保存する方式ではなく、SE050 内部でプライベートキーを生成・保存して、対応する証明書を取り出して使う、という仕組みです。
>もしそうであれば具体的な設定コマンドをご教示いただきたくお願いいたします。
se05x_setkey を含め、弊社から提供していますビルド済みの SE050 Plug&Trust MW パッケージでは対応できないため、ご自分でビルドして頂く必要があると思います。
SE050 Plug&Trust MW のビルド手順は、以下の Howto で説明しています：
EdgeLock SE050 Plug&Trust MW ビルド手順 (Armadillo-IoT A6)
https://armadillo.atmark-techno.com/howto/aiot_a6-se050-build_middle_wa…
Greengrass で PKCS#11 に SE050 を使用する場合の手順は、SE050 Plug&Trust MW のアーカイブの中の
simw-top/demos/linux/green_grass/
にある README で説明されています。
なお、この README で説明されている手順は、Greengrass Core v1.x を対象にしています。
そのため、v2 で導入された PKCS#11 プロバイダを provisioning plugin として使用する方式ではありません。
provisioning plugin を使わなければ v1.x の場合と同様の設定で v2 に対応できるのかどうかは、不明です。
弊社では、Greengrass Core で SE050 の証明書を使ったことがありませんので、現時点では、これ以上のアドバイスをできません。
ところで、以下の背景について、二点教えて頂けますか。
><背景>
>AWS IoT Greengrass V2 を動作させようとする場合、AWS が提供する PKCS#11 プロバイダ (aws.greengrass.crypto.Pkcs11Provider) コンポーネントにより、使用する HSM に対して以下のような要件があります:
>
>・プライベートキーと証明書は HSM の同じスロットに保存する必要があり、HSM がオブジェクト ID をサポートしている場合、同じオブジェクトラベルとオブジェクト ID を使用する必要があります。
>(以上 https://docs.aws.amazon.com/ja_jp/greengrass/v2/developerguide/hardware… および https://docs.aws.amazon.com/ja_jp/greengrass/v2/developerguide/pkcs11-p… より転記)
>
>既存の証明書と鍵は上記条件に当てはまらないためか、Greengrass 起動時に "Private key and certificate labels must be the same" のエラーログが生じ AWS IoT との接続を確立することできませんでした。
Q1: 「既存の証明書と鍵」とおっしゃっているのは、何を指しているでしょうか？
以下の Howto で説明している証明書と、リファレンスキーのことでしょうか：
EdgeLock SE050 Plug&Trust MW のビルド済みパッケージのインストールと証明書の取得 (Armadillo-IoT A6)
https://armadillo.atmark-techno.com/howto/install_plug_and_trust_mw_for…
Q2: Greengrass Core v2 は、Debian ベースのコンテナ内で動作させていらっしゃるという認識で、合っているでしょうか？
以上、ひとまずのコメントです。