はじめまして。mtdev と申します。
github の iot-reference-rx をベースにCK-RX65Nで AWS IoT Coreへの接続を検証しています（これ自体はとても簡単でした）。現在，鍵合意にx25519を使いたい場合などのために，mbedTLSのソフトウェア実装でセッションキーを生成し、AESの暗号アクセラレータとしてのみTSIPを使うことができないか調べております。
TLS1.2の場合、TSIPが想定する本来の流れはR_TSIP_TlsGenerateSessionKey() で AES用のWrapped Key を取得し，R_TSIP_Aes* 関数を用いて暗号化・復号化することだと思います。R_TSIP_TlsGenerateSessionKey() の代わりにmbedTLSのソフトウェア実装でラップされていない生の暗号鍵を生成し，これを実行時にラップしてR_TSIP_Aes* 関数に渡すことは可能なのでしょうか？
mtdevさん
こんにちは、シェルティです。ルネサスの中の人です。
RX65Nマイコン活用いただきありがとうございます。
>>R_TSIP_TlsGenerateSessionKey() の代わりにmbedTLSのソフトウェア実装でラップされていない生の暗号鍵を生成し，これを実行時にラップしてR_TSIP_Aes* 関数に渡すことは可能なのでしょうか？
こちら残念ながらできないですね。TSIPは平文鍵の入力を禁止しています。セキュリティ実装の考え方として、「暗号境界」という考え方があり、「暗号境界」外に平文鍵を配置するとそのシステムは安全ではない、という定義になっています。そしていわゆる汎用マイコンでは内蔵ROMやRAMは「暗号境界」外でして、いわゆる汎用マイコンは安全ではない、ということが通常です。
RXマイコンではTSIPをマイコン内蔵セキュリティIPとして実装しておりまして、TSIPの内部は「暗号境界」内ですので、安全です。どのくらい安全かというとNIST FIPS140-2 CMVP level3という検定に合格できるくらい安全です。
https://www.renesas.com/jp/ja/about/press-room/renesas-rx-mcu-becomes-world-s-first-general-purpose-mcu-obtain-cmvp-level-3-certification-under
TLSの実装を平文鍵が「暗号境界」内でのみハンドルされるようにするためには、TLSの基点となるマスターシークレットを乱数から生成する処理自体をTSIP内部で行う必要があり、R_TSIP_TlsGenerateSessionKey()はまさにこの関数に相当し、R_TSIP_TlsXxxxx() という接頭語が付いたAPIを利用する必要があります。これでTLSを「暗号境界」の考えに則り安全に実装することができます。代表例としてFreeRTOSとよく組み合わせて利用されるmbed TLSについて、具体的な実装方法を以下アプリケーションノートで解説しています。
https://www.renesas.com/jp/ja/software-tool/trusted-secure-ip-driver
-> RXファミリ TSIPドライバを用いたTLS実装方法 Rev.1.02
Azure RTOSをTSIP対応させる方法もあります。
-> RXファミリTSIPドライバを用いたTLS実装例（Azure RTOS） Rev.2.00
ただこれら、かなりハードルが高いものになっていて、多くのマイコンユーザは「暗号境界」の考え方を一旦横に置いておいて、「暗号IPをAESのアクセラレータとして利用する」と考えるのもとても合理的です。RAファミリでは平文鍵を通常RAM上に配置したマスターシークレット等をTrustZoneで保護する、という考え方の元、暗号IPに平文鍵入力を許容しています。RAファミリを利用するのもひとつの解法かもしれません。またRXファミリでも今後平文鍵入力についてポシリー再検討などを進める可能性があるかもしれません。
以上です
シェルティです、こんにちは。
「TLSの基点となるマスターシークレットを乱数から生成する処理自体をTSIP内部で行う必要があり、R_TSIP_TlsGenerateSessionKey()はまさにこの関数に相当」が間違っていたので修正します。
「R_TSIP_TlsGeneratePreMasterSecret()」が正しいです。
またこのあたりTLS関連の関数の使用方法の情報を知りたい場合はウェブ掲載しているバイナリ版のマニュアルには載せていなので、ソースコード版のTSIPドライバを取り寄せるのが良いですね。TSIP情報に関して適正な輸出管理のため若干情報公開具合が難解になっていてすみません。
シェルティさま
丁寧にご教示くださりありがとうございます。RXファミリでは意図的に平文鍵の入力を許可しておられないとのこと，RAファミリだとARMのTrustZoneで平文鍵の入力ができるとのこと，とてもよく理解できました。
実は，「RXファミリ TSIPドライバを用いたTLS実装方法」は拝見させていただいておりました。mbedTLSの内部をかなり変えておられるので，mbedTLSのバージョンアップやTLS 1.3 対応，iot-reference-rx のPKCS#11と組み合わせることが私の能力では厳しそうだなと思っておりました。
それで，PSAベースのopaque keyとしてTSIPを使うことを検討していたのですが，mbedTLSの現在の実装は鍵合意で得られた秘密共有の平文を要求しており，平文鍵の入力ができるかどうかご質問させていただいた次第です（R_TSIP_TlsGeneratePreMasterSecretで得られた秘密共有の平文が必要）。TSIPの暗号境界の考え方に，mbedTLSがまだ追いついていない状態なのですね。
mbedTLSのPSA driver としてTSIPを使い，デバイス証明書の秘密鍵をopaque key として使う処理は手元で動いております。Wrapped KeyがMCU固有のキーになるのでぜひ使っていきたいと思っております。
この度はご教示いただきありがとうございました。
ご検討ありがとうございます。種々調査いただき記載いただいた上記内容が正しいことを確認しました。また、「RXファミリ TSIPドライバを用いたTLS実装方法」をご参照いただきありがとうございます。オープンソースであるmbed TLSを改造する手段は私としても苦渋の決断でした。
また、「TSIPの暗号境界の考え方に，mbedTLSがまだ追いついていない状態」というよりは「mbed TLSも暗号境界の考え方は理解しているが市場要求がまだそこまで成熟しておらず、あるいはTrustZoneを使えば平文鍵を通常のメモリ空間に配置してもセキュリティリスク無しと見做し、mbed TLSに代表されるTLS実装体はTSIPのような特殊性をカバーするような実装になっていない」という表現の方が適切かもしれません。
このあたりルネサスのパートナーのユビキタスAI社や、wolfSSL社がTSIPをうまく活用して秘密鍵が通常RAMに露出しないように配慮した版のTLS実装コードをお持ちですので、製品開発まで進まれる際にはパートナーともご相談いただけると、高いセキュリティ性を確保したTLSスタックをマイコンに実装する手段をご提供いただけるものと思います。
ルネサスとしてはプリミティブ部分にあるTSIPドライバの開発を継続し、TLS1.3などの新しい技術に対応できるAPIを適宜追加していく考えです。そしてその都度、関係パートナーやmbed TLSなどのオープンソースと連携強化を図ってまいります。
↑すみません、すこし書き間違えました。修正します。
誤：TLS1.3などの新しい技術に対応できるAPIを適宜追加していく考えです。
正：TLS1.3などの新しい技術に対応できるAPIを適宜追加していく考えです。TLS1.3についてはTSIPドライバとしては対応済でユビキタスAI社のソリューションと結合確認ができています。https://www.renesas.com/jp/ja/software-tool/trusted-secure-ip-driver
パートナーさまについての情報をありがとうございます。
パートナーさまへのご相談や，iot-reference-rx の network_transport をwolfSSL に差し替えることも検討してみたいと思います。
この度は多くの点をご教示いただき，またお時間を頂戴してありがとうございました。