米Microchip Technologyは米国時間の9月30日、同社の認証ソリューション「CryptoAuthentificationファミリ」向けに「Trust Platform」と呼ばれるプロビジョニングサービスを開始したことを発表した。この発表に先立ち、同社は日本でも説明会を開催。本社より、セキュリティ製品グループのVPを務めるNuri Dagdeviren博士(Photo01)が来日し、説明を行った。

  • Microchip

    Photo01:説明を行われたのNuri Dagdeviren博士(VP, Security Products Group)

もともとMicrochipは、旧Atmelの流れを汲むセキュリティ製品を製品ポートフォリオとして抱えており(他にも旧MicroSemiの流れを汲むSecurity IPなどもある)、そうした製品ポートフォリオの延長として、2017年11月に「ATECC608A」という暗号化ソリューションをリリースしている

発売時期から言えばMicrochipによるAtmelの買収後(買収から1年半後)ではあるが、この手の製品は設計開始から出荷まで1年以上かかる事と、型番がATから始まるあたりから推察すると、恐らく企画と設計開始はMicrochipによる買収前からスタートしており、買収後に製品出荷という形になったものと思われる。

さて今回の発表は、このATECC608Aを対象としたものである。ATECC608A自身はハードウェアセキュリティコプロセッサであり、最大16個の秘密鍵と楕円暗号を含む複数種類の暗号化/復号化処理を行う事が出来る、暗号化アクセラレータ+セキュアストレージとでもいうべき製品である。このATECC608Aの大きな強みは、3大IoT Cloud(AWS IoT、Google IoT Cloud、Microsoft Azure IoT)への認証をサポートしている(ほかにLoRAへの認証も提供される)ことで、手持ちの機器をこうしたIoT Cloudに接続できるようにしたいと考えた場合、ATECC608Aを外付けの形で機器のMCUなりMPUに接続するだけでハードウェア側の準備は整うことになる。

ここで問題になるのは、もちろんこうしたIoT CloudなりLoRaなりに接続するためのソフトウェア側の改修もさることながら、暗号化キーのProvisioning(プロビジョニング)が必要な事である。一般論としては、どこかしらの暗号局から証明書付きでキーを入手。まずATECC608AのSecure Storageにキーを格納した上で、ターゲットとなるCloudに証明書を登録することで、ATECC608AがそのCloudにアクセス可能となる。ただこれをいちいち行うのは大変に面倒である(Photo02)。実際「俺は単にAWS IoTとつなぎたいだけなんだよ」などと現場が愚痴るケースも少なく無い訳で、そうしたケースでいちいち証明書サービスを探して契約してキーと証明書を取得して…というのは、セキュアなソリューションを提供する際のボトルネックになるのは間違いない。

  • Microchip

    Photo02:そもそもどんなところに接続するために、どんな証明書とキーを何種類用意して、どうやってそれぞれの接続先につなぐか、というあたりは当然アプリケーション開発者が考えて手配を行う必要がある

今回発表されたプロビジョニングサービスはまさにこの点を解決するためのものである。端的に言えば、このサービスではMicrochip側で証明書の取得を代行、ATECC608Aにキーの格納まで行った状態で開発者に出荷を行う。開発者はMicrochipから提供された証明書をそれぞれのCloudなりLoRaのプロバイダに登録して、あとはチップを機器に装着するだけでそれぞれのCloudなりLoRaなりに接続できる、という訳だ。

このサービスは3種類の形態で提供される。一番簡単なのが「Trust&Go」、一番複雑なのが「TrustCUSTOM」で、「TrustFLEX」というのがその中間に位置する。目玉となるTrust&Goは、対応する相手を3大Cloud+LoRaに限る事で、面倒なカスタマイズを最小限に抑えた仕組みである(Photo04,05)。特定のサービスにつなぐというだけであれば、これで十分である。なにより10個という非常に少ない数からのオーダーが可能になっているのが、少量多品種向けには嬉しい配慮である。

  • Microchip

    Photo03:Trust&Goは当初最小個数が100個単位だった模様だが、最終的には10個という非常に少ない数量でのオーダーが可能になった

  • Microchip

    Photo04:TLS認証にも当然対応する

  • Microchip

    Photo05:選択は事実上、最初に「どのサービスに接続するか」だけで、あとはすぐ試作に入って製品化が可能

  • Microchip

    Photo06:Trust&Goの手続き。証明書などはマニフェストの形で提供される

もう少し複雑な、例えば「AWS IoTとAzure IoTの両方に接続し、しかも接続方法がLoRa」などというケースでは、Trust&Goだと3つのATECC608Aチップが必要になる。チップの機能的にはこの3種類の接続を1チップで格納可能であるが、モデル的にそれぞれのチップが1種類の接続しか考慮していないためである。こうしたケースではTrust&Goよりも柔軟性を高めたものが望ましい。そういうニーズに向けて提供されるのがTrustFLEXである(Photo07,08)。

  • Microchip

    Photo07:Trust Flexでは色々カスタマイズが可能になる分、開発者もセキュリティに対しての知識が必要になる

  • Microchip

    Photo08:最小発注個数は若干増えるが、それでも2000個というのはかなり少なめである

完全にカスタマイズ可能、というのがTrustCUSTOM(Photo09,10)で、こちらは最小発注個数が(スライドにもあるが)4000個と若干多くはなるものの、それでも従来とは2桁ほど個数が小さくなっている。

  • Microchip

    Photo09:従来、メーカーによるプロビジョニングサービスと言えば、このTrustCUSTOMに近いものが多かった。そういう意味では、これが従来型のプロビジョニングサービスという事も出来るだろう

  • Microchip

    Photo10:暗号化方式などの手順まで含めて完全にカスタマイズできるので、その意味では独自の暗号化方式とか鍵交換手順などの実装も可能である。もっともその分開発負荷も高くなることとなる

「どのサービスを選ぶのが一番適切か」のダイアグラムがこちら(Photo11,12)である。とりあえず主要なクラウドサービスにつなぐ、あるいはLoRaにつなぐというだけであれば、Trust&Goを選ぶだけで、非常に手軽に利用できる様に配慮されている形だ。

  • Microchip

    Photo11:Trust&Goの要件は、要するに「Microchipが提供する4種類の接続方法だけで十分か?」であり、TrustFLEXは「Microchipの提供するものの組み合わせだけで行けるか?」と置き換えれば判りやすい

  • Microchip

    Photo12:TrustCUSTOMについては、必要に応じて同社のコンサルティングサービスやテクニカルサポートも併用する形になるのだろうが、これは従来型のサービスそのものでもある

ちなみに、それぞれのクラウドソリューションも併せて提供される。AWS IoT Core(Photo13)、Google IoT Core(Photo14)、Azure IoT(Photo15)、LoRa(Photo16)などで、他にもwolfSSLやMbed、さらにArduinoなどへのサポートも予定されているそうだ(Photo17)。

  • Microchip

    Photo13:AWSといっても色々あり、同社はすでにGreangrass向けソリューションなども提供している訳で、こうしたものもATECC608Aを利用しているので、そのままTrust&GoないしTrustFLEXが利用できることになる

  • Microchip

    Photo14:PIC24やATMega4809などの場合も、Secure ElementはATECC608Aが利用される

  • Microchip

    Photo15:Azure IoT向けソリューションは現在はSAMA5D28ベースがメイン

  • Microchip

    Photo16:こちらはSAMR34(Cortex-M0+のMCUにLoRaのトランシーバを搭載したSiP)ベースというのがメイン

  • Microchip

    Photo17:この原稿執筆時点ではまだこれらの詳細は明らかにされていない

ところで、既存の製品に後付けするという意味では、ATECC608Aとこれに対応するプロビジョニングサービスは良い選択肢になると思うが、これから新規に開発するというケースでは、Photo13~Photo16のソリューション(MCU/MPU+ATECC608A)よりも、こうしたSecure Elementを最初から搭載したSecure MCUを利用する方がむしろ便利ではないか? という考え方は当然ある。

このあたりをDagdeviren博士に伺ったところ、「確かにそういう製品もあるが、セキュリティの実装を容易かつ堅固にするためには、完全に分離したほうがむしろ楽になる。例えばチップを統合してしまうと、Side Channel Attackの類の影響を受けやすくなるし、本体(MPU/MCU)のPower Mode切り替えのタイミングを狙う攻撃などもあり得る訳で、むしろ分離したほうが好ましいと考えている」という見解であった。このあたりをどう考えるかはユーザーによって異なるだろうが、1つの見識ではあるだろう。少なくともプロビジョニングの手間を考えると、チップを分離したほうが(小規模な生産においては)楽そうである。また最小発注個数の少なさも魅力的である。セキュリティチップそのものはMicrochip以外にも複数社から提供されているが、選択に当たっては単にチップ単体ではなくプロビジョニングの手間も考慮すべし、というのがMicrochipのメッセージであり、そのメッセージに合わせて魅力的なサービスを同時に提供する事にしたのが今回の発表ということとなるだろう。