本記事では、i.MX 93内蔵のEdgeLock® Secure Enclave(ELE)の暗号アクセラレータおよび鍵管理の機能をPKCS#11経由で使用する方法について解説いたします。
PKCS#11は暗号処理において広く使用されているAPIであり、同じく広く使用されているライブラリであるOpenSSLとの統合も可能です。そのためPKCS#11やOpenSSLを使用した認証処理を行うアプリケーション全て(例: Eclipse Mosquitto™ etc.)に対して、アプリケーション側の改造無しで保護機能の適用も可能です。
暗号アクセラレータおよび鍵管理の機能を提供するという点は別記事で紹介しているSE050などのセキュアエレメントとも共通します。
暗号アクセラレータおよび鍵管理の概要、セキュアエレメントとの大まかな比較や使い分けは以下の記事も参照ください。
作業時間: 約55分 (yoctoのビルド除く)
- pkcs11-tool経由でのELEの使用 : 10分
- openssl経由でのELEの使用 : 10分
- PKCS#11 URI PEMファイルの作成 : 5分
- Azure IoT Hubへのクラウド接続 : 30分
動作確認に使用した環境
ハードウェア:
- FRDM i.MX 93開発ボード (FRDM-IMX93)
- MicroSDカード32GB (SDカードにイメージを書き込んで使用する場合。16GBでも動作すると思われます)
ソフトウェア:
- Linux BSP Version L6.18.2-1.0.0
※FRDM-IMX93のwebページにあるビルド済みイメージでは正常に動作しないため、以下を参考にビルドください。
[入門] Yocto Linux BSPのビルド方法 - i.MX FRDMボード編 (日本語ブログ)
私がビルドした際はrepo initおよびimx-setup-release.sh実行時のコマンドに以下を使用しました。
repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-whinlatter -m imx-6.18.2-1.0.0.xml
DISTRO=fsl-imx-wayland MACHINE=imx93-11x11-lpddr4x-frdm source imx-setup-release.sh -b ./buildEdgeLock® Secure Enclave(ELE)の概要
i.MX 93における「EdgeLock® Secure Enclave(ELE)」は、NXPが提供する暗号アクセラレータ、鍵管理、SoC全体の監視やアクセス権限管理など多数の高度なセキュリティ機能を統合したセキュリティブロックです。
SoC全体の監視やアクセス権限管理という点では代表的な機能としてセキュアブートがあります。i.MX 93のセキュアブートおよびその使用方法に関しては以下の記事を参照ください。
本記事では暗号アクセラレータおよび鍵管理の機能をPKCS#11経由で使用する方法について解説いたします。
i.MX Security Middleware(SMW)の概要
NXPはi.MXプロセッサ内蔵のセキュリティハードウェアを制御するためのソフトウェアとしてi.MX SMW(Security Middleware)を提供しています。
SMWはハードウェアに依存しないAPIを提供します。これには後述するPKCS#11のAPIも含みます。
i.MX 93ではELEが内蔵されているため、実際にELEを制御する部分はimx-secure-enclaveが使用されます。
PKCS#11の概要
PKCS#11（Public-Key Cryptography Standards #11）は、暗号処理を行うハードウェアやソフトウェア（例：HSM、スマートカード、USBトークンなど）をアプリケーションから統一的に利用するためのAPI仕様です。別名「Cryptoki（クリプトキー）」とも呼ばれます。
PKCS#11を使用するアプリケーションとして、今回はpkcs11-toolを使用します。
imx-smwを含めた関係を図示すると以下のようになります。
PKCS#11を使用するアプリケーション(pkcs11-tool etc.)
↓ (PKCS#11 API経由での使用)
imx-smw
↓
imx-secure-enclave
↓
EdgeLock Secure Enclave Hardwareまた、以前のOpenSSL経由でのSE050の使用方法の記事では、Plug and Trust Middlewareに含まれるopenssl providerを使用してopenssl経由での使用方法を解説しました。
SMWはopenssl providerを提供しませんが、pkcs11-providerを使用することでopensslからPKCS#11のインターフェースを使用可能なため、openssl経由でのELEの使用も可能です。
GitHub - openssl-projects/pkcs11-provider: A pkcs#11 provider for OpenSSL 3.0+ · GitHub
OpenSSL provider非使用時と、imx-smw + PKCSを使用する場合の関係を図示すると以下のようになります。
Provider非使用時はkeyがファイルとしてファイルシステム上に存在し、暗号処理もソフトウェアにより行われます。
imx-smwおよびpkcs11-provider使用時はkeyおよび暗号処理はELEハードウェアにより保護されます。使用するkeyはコード上またはファイルシステム上にあるPKCS#11 URIにより指定します。
※URI(uri)とは？:
ハードウェア・セキュリティ・モジュール（HSM）などに安全に保管された秘密鍵や証明書を、ローカルファイルのパスの代わりに指定するための標準化された識別子（URI）です。
note : Plug and Trust MiddlewareもPKCS#11のAPIを提供しています。
pkcs11-tool経由でのELEの使用
使用方法はSMW内のPKCS11-Tool User Guideに記載がありますが、ECDSA署名および検証に絞って一連の流れを説明します。
まず以下コマンドを実行してnvm_daemonを起動します。
nvm_daemonはELEを使用するためにファイルシステム領域を管理するサービスです。
systemctl start nvm_daemon
systemctl status nvm_daemon以下コマンドを実行することで次回起動時に自動で起動するようにもできます。
systemctl enable nvm_daemon以降のコマンドを簡略化するため、以下コマンドでlibsmw_pkcs11の場所を指定します。
末尾の番号はsmwのバージョンによって変わる可能性があるためインストール済みのものに合わせてください。
export MODULE_PKCS11=/usr/lib/libsmw_pkcs11.so.5以下コマンドでlibsmw_pkcs11経由で確認可能なトークンを確認します。
pkcs11-tool --module $MODULE_PKCS11 -L以下の例のような表示がされれば問題なく動作しています。
Available slots:
Slot 0 (0x0): Security Middleware Abstraction
token label : smw
token manufacturer : NXP Semiconductor
token model :
token flags : login required, PIN pad present, token initialized
hardware version : 0.0
firmware version : 0.0
serial num :
pin min/max : 0/0
uri : pkcs11:model=;manufacturer=NXP%20Semiconductor;serial=;token=smw以下コマンドで利用可能なオブジェクトの一覧を表示します。
最初は何も表示されないはずです。
pkcs11-tool --module $MODULE_PKCS11 --login -O以下コマンドでECC key pairを生成します。
pkcs11-tool --module $MODULE_PKCS11 \
--login \
--keypairgen \
--key-type EC:prime256v1 \
--id 02 \
--label "MyECCKey" \
--usage-sign \
--allowed-mechanisms "ECDSA-SHA256"再度オブジェクト一覧を表示すると以下のようにECC key pairが見えるはずです。
Using slot 0 with a present token (0x0)
Profile object 250360144
profile_id: CKP_BASELINE_PROVIDER (1)
Public Key Object; EC EC_POINT 256 bits
EC_POINT: 044104fe4c97a7a4f54702f9fc5740f62c0864e851098dc43cb4c9ba8633421e5bc362cdc559523118bb4fe4281851c051e24a88846a2d774eb3f928595761cf719e90
EC_PARAMS: 06082a8648ce3d030107 (OID 1.2.840.10045.3.1.7)
label: MyECCKey
ID: 02
Usage: verify
Access: none
Unique ID:
uri: pkcs11:model=;manufacturer=NXP%20Semiconductor;serial=;token=smw;id=%02;object=MyECCKey;type=public
Private Key Object; EC
label: MyECCKey
ID: 02
Usage: sign
Access: sensitive, always sensitive
Unique ID:
uri: pkcs11:model=;manufacturer=NXP%20Semiconductor;serial=;token=smw;id=%02;object=MyECCKey;type=private以下コマンドで適当なmessage.txtファイルを生成、それに対して署名の生成及び検証を行うことができます。
echo hello > message.txt
pkcs11-tool --module $MODULE_PKCS11 \
--login \
--sign \
--id 02 \
--mechanism ECDSA-SHA256 \
--input-file message.txt \
--output-file signature.bin
pkcs11-tool --module $MODULE_PKCS11 \
--login \
--verify \
--id 02 \
--mechanism ECDSA-SHA256 \
--input-file message.txt \
--signature-file signature.binopenssl経由でのELEの使用
同様にECDSA署名および検証に絞って一連の流れを説明します。
前章のpkcs11-tool用の手順によってnvm_daemonの起動及びECC key pairの生成が完了している前提です。
以下の内容のopenssl.cnfを作成します。
末尾のmoduleおよびpkcs11-module-pathの行は、実際のシステムに合わせて変更が必要な可能性があります。
openssl_conf = openssl_init
[openssl_init]
providers = provider_sect
[provider_sect]
default = default_sect
pkcs11 = pkcs11_sect
[default_sect]
activate = 1
[pkcs11_sect]
module = /usr/lib/ossl-modules/pkcs11.so
pkcs11-module-path = /usr/lib/libsmw_pkcs11.so.5
activate = 1以下コマンドで上記設定ファイルをopensslで使用するよう設定します。
export OPENSSL_CONF=<作成したopenssl.cnfの絶対path>以下コマンドで署名生成及び検証が可能です。
openssl pkeyutl -sign -inkey "pkcs11:object=MyECCKey;type=private" -in message.txt -out sig.bin -digest sha256
openssl pkeyutl -verify -pubin -inkey "pkcs11:object=MyECCKey;type=public" -in message.txt -sigfile sig.bin -digest sha256PKCS#11 URI PEMファイルの作成
openssl providerの使用方法では、keyに直接オブジェクト一覧で確認可能なURIを使用しました。
しかしpkcs11-providerのドキュメントの "USE IN OLDER APPLICATIONS (URIs in PEM files)" には、これは新しい方法であり、従来のアプリケーションを使用する場合はこの方法が使用できない場合がある旨記載があります。
実際後述のMosquitto clientでは、openssl 3.0以降を使用する場合、URIを直接指定できないコードとなっていました。
このような場合、CLI tool uri2pem.pyを使用することでURIを含むファイルを生成し、通常の鍵ファイルを指定するのと同じ方法で使用することが可能です。
上記ページからダウンロードしたuri2pem.pyを使用し、以下コマンドでPKCS#11 URIを含むファイルを生成します。
python3 uri2pem.py --out MyECCKey.pem "pkcs11:object=MyECCKey;type=private"詳細は確認できておりませんが、uri2pem.pyの内容を確認する限りprivate key以外のURIのpemファイルは作成できないようです。
生成された「MyECCKey.pem」を署名時のkeyとして指定することで先ほどと同様の動作が可能です。
openssl pkeyutl -sign -inkey MyECCKey.pem -in message.txt -out sig.bin -digest sha256
openssl pkeyutl -verify -pubin -inkey "pkcs11:object=MyECCKey;type=public" -in message.txt -sigfile sig.bin -digest sha256ELE内の鍵を使用したEclipse Mosquitto™ client経由でのAzure IoT Hubへのクラウド接続
生成した鍵を使用してMosquitto clientを使用したAzure IoT Hubへのクラウド接続を試みます。
注: この手順で作成するRootCA証明書はあくまでテスト用です。テスト完了後はAzure IoT Hub上から証明書を削除することを推奨します。
事前に
の「Mosquitto clientのビルドとインストール」の章
の「Azure IoT Hubの作成」の章、
それぞれの手順を行い、Mosquitto clientのインストールおよびAzure IoT Hubの作成を完了させてください。
まずFRDM-IMX93側で以下コマンドを実行しMyECCKeyのpublic keyに対する証明書リクエストを作成、内容を確認します。
openssl req -new -key "pkcs11:object=MyECCKey" -outform PEM -subj /CN=frdmimx93_test -out frdmimx93_test.csr -sha256
openssl req -text -noout -in frdmimx93_test.csrその後ホストPC側に「frdmimx93_test.csr」を移動し、以下を実行します。
openssl ecparam -genkey -name prime256v1 -out rootCA_key_pair.pem
openssl req -new -x509 -subj /CN=rootCA -key rootCA_key_pair.pem > rootCA_cert.cer
openssl x509 -req -in frdmimx93_test.csr -days 365 -CA rootCA_cert.cer -CAkey rootCA_key_pair.pem -out frdmimx93_test_cert.cer作成した「frdmimx93_test_cert.cer」をFRDM-IMX93に戻します。後ほど「MyECCKey.pem」とセットで使用するため、そちらを作成したディレクトリに置きます。
また、Azure IoT Hubにて、作成した「rootCA_cert.cer」の登録、「frdmimx93_test」という名前のデバイスの作成を行います。
手順は以下記事の「Azure IoT Hubへの中間CA証明書の追加」の章を参照ください。
注 : 前述のとおりここで登録した証明書はテスト用のため、動作確認後は削除を推奨します。
ここまでの手順を終えるとMosquitto clientを使用してAzure IoT Hubへの接続が可能になります。
以下コマンドを実行します。IOT_HUB_NAMEは適宜変更ください。
export IOT_HUB_NAME=ShinjiIotHubTest
export DEVICE_NAME=frdmimx93_test
mosquitto_pub -h "${IOT_HUB_NAME}.azure-devices.net" -p 8883 -u "${IOT_HUB_NAME}.azure-devices.net/${DEVICE_NAME}/api-version=2016-11-14" -t "devices/${DEVICE_NAME}/messages/events/" -m '{"mes":"Hello Azure with i.MX93!"}' --capath /etc/ssl/certs/ --cert frdmimx93_test_cert.cer --key MyECCKey.pem -i ${DEVICE_NAME} -d -q 1以下のような出力が出れば成功です。
Client frdmimx93_test sending CONNECT
Client frdmimx93_test received CONNACK (0)
Client frdmimx93_test sending PUBLISH (d0, q1, r0, m1, 'devices/frdmimx93_test/messages/events/', ... (34 bytes))
Client frdmimx93_test received PUBACK (Mid: 1, RC:0)
Client frdmimx93_test sending DISCONNECT以下記事の「IoT Hubへ送信されたメッセージの確認とデバイスへのメッセージ送信」の手順を使用するとAzure IoT Hub側のCloud Shellでも受信メッセージを確認できます。
=========================
本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。
お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。
（既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。）
本記事では、i.MX 93内蔵のEdgeLock® Secure Enclave(ELE)の暗号アクセラレータおよび鍵管理の機能をPKCS#11経由で使用する方法について解説いたします。
PKCS#11は暗号処理において広く使用されているAPIであり、同じく広く使用されているライブラリであるOpenSSLとの統合も可能です。そのためPKCS#11やOpenSSLを使用した認証処理を行うアプリケーション全て(例: Eclipse Mosquitto™ etc.)に対して、アプリケーション側の改造無しで保護機能の適用も可能です。
暗号アクセラレータおよび鍵管理の機能を提供するという点は別記事で紹介しているSE050などのセキュアエレメントとも共通します。
暗号アクセラレータおよび鍵管理の概要、セキュアエレメントとの大まかな比較や使い分けは以下の記事も参照ください。
作業時間: 約55分 (yoctoのビルド除く)
- pkcs11-tool経由でのELEの使用 : 10分
- openssl経由でのELEの使用 : 10分
- PKCS#11 URI PEMファイルの作成 : 5分
- Azure IoT Hubへのクラウド接続 : 30分