本番稼働でわかった秘匿化技術のチャレンジングなこと

こんにちは！LayerX LabsでAnonifyを開発しているエンジニアの恩田（さいぺ）です。

この記事はLayerX 2021アドベントカレンダー 13日目の記事です。昨日はmosaさんのLayerXのカルチャーと行動指針 (2021年版)でした。明日はken5さんの記事が公開される予定です。

Anonify概略

Anonifyについては以前、秘匿化モジュールAnonifyにおけるRust featuresを活用した開発 - LayerX エンジニアブログで紹介させて頂いただいたので詳細はブログをご覧ください。要約するとAnonifyは「秘匿性」と「透明性」という相反する２つの性質を両立する秘匿化モジュールです。要素技術はTrusted Execution Environment（TEE）で、より具体的にはIntel SGX®︎を採用しています。

いよいよ始まったAnonify本番稼働

海外では、Intel SGXを用いたDemetics社の医療イノベーションの事例なども登場してきており、徐々にIntel SGXの本番稼働が色づいてきています。

そんな中、9月21日から10月11日にかけて実施されたつくば市様の『つくば市科学技術・イノベーション振興指針』の策定に向けたWEBアンケートでAnonifyを秘匿集計基盤として採用いただきました。本件は、実際に一般の方々が触れる基盤として、Anonifyが本番で利用される一号案件となりました。

f:id:cipepser:20211012200555p:plain

（ https://www.city.tsukuba.lg.jp/_res/projects/default_project/_page_/001/015/751/flyer.pdf より引用）

本番稼働となるわけなので、当然に正常系・異常系を網羅的に実施し、負荷試験、障害試験といった試験も十分行いました。その他にも運用・監視体制も組み、結果として無事、実施期間を終えることができました。ただしこれらはシステムの本番稼働では一般的な話です。私自身金融SIer出身であったり、メンバーもサービス運用経験者だったので、これらの事前準備は当たり前のことを当たり前にやるというものでした。¹

TEEならではの難しさ

いざAnonifyを本番稼働させるとなったことで、TEEならではの難しさにも直面しました。冒頭で言及したブログで触れたようなno-std制約による開発難易度の高さという話もあるのですが、本番稼働という文脈においては「いざ障害が起こったときに復旧が可能なのか」が一番の困難でした。

TEEを始めとする秘匿化技術はその名の通り、秘匿化が売りです。

Anonifyでいえば、クライアントからのリクエストは公開鍵暗号²で暗号化されます。この公開鍵に対応する秘密鍵はTEEの中から一切外に出ることはありません。 さて、本番サービスを運用されている方であれば、いざというときに原因究明、復旧ができるよう、サーバやアプリケーションのログやバックアップを入念に準備するのではないでしょうか。これらログやバックアップはサービス継続の最後の砦であり、一エンジニアとしても大きな心の拠り所です。しかしAnonifyではTEEの中から一切秘密鍵が出ないという売りが牙を剥きます。リクエストが復号され、平文となるのはTEEの中だけです。メモリ上でもenclaveと呼ばれる隔離保護された領域で暗号化されており、平文になるのはCPUで計算する時にだけです。

つまりいくらデータのバックアップを取っていても、それは暗号化されたリクエストであり、TEEに対応するCPUがなければ復旧できない無用の長物でしかないのです。

特にAnonifyは Azure Confidential Computing VMでAnonifyを動かそう - LayerX エンジニアブログで紹介した通り、Azure Confidential Computing VM上に構築しています。そのため、メンテナンス等でVMと物理マシン（より詳細にはCPU）の紐付けが一度解除されてしまうと、再度同じCPUが割り当てられる保証がありません。そして何より、クラウドプロバイダー側でスケジュールされるメンテナンスは我々がコントロールできるものではありません。メンテナンスは2020年の実績で言えば3回ほど発生しています。

チームメンバー一同、サービス運用経験者だったからこそ、いざというときに復旧ができないかもしれないという事実は大きな恐怖でした。

Anonifyでの対策

Anonifyでは、これに対応するためkey-vaultノードを設計に組み込んでいます。key-vaultノードもAnonifyノードと同様にIntel SGX上に構築されますが、Anonifyノードとは異なるVM（CPUも異なる）上に構築します。実際にはAzure Kubernetes Service（AKS）を用いて構築しているので、Anonify podとkey-vault podが存在し、それぞれのpodが別のnode上で稼働するアーキテクチャです。

そして、Anonifyノード〜key-vaultノード間はmutual-TLS（mTLS）で接続しています。

f:id:cipepser:20211012202126p:plain

みなさんが普段ブラウザなどでWebサイトを閲覧する際のTLSでは、サーバ証明書がルート証明書から辿ることのできる正規の証明書であることを検証し、セキュアなコネクションを張ります。Anonifyノードとkey-vaultノード間のmTLSコネクションでは、お互いに想定通りのプログラムが動作していることを検証しています。

この「お互いに想定通りのプログラムが動作していることを検証」を実現するために、Intel SGXで提供されているRemote Attestationと呼ばれる機能を利用します。

f:id:cipepser:20211012201910p:plain

Remote Attestaitonでは、Intelが工場製造時に焼き付けた鍵を使って正規のCPUであることを検証の上、実行コード³にIntel秘密鍵で署名を付与してくれます。そしてこの署名はpodのdocker imageビルド時とruntimeに得ることができます。Anonifyノードとkey-vaultノードはimageビルド時点で、お互いのmeasumentを知ることができます。そして実際に秘密鍵をバックアップするruntimeに、相手が事前に取り決めた相手であることを認証の上、mTLSコネクションを結びます。このmTLSコネクションはAnonifyノードのTEE内〜key-vaultノードのTEE内で結ばれており、このコネクションを介して秘密鍵をセキュアにバックアップすることができます。このようにして、万が一Anonifyノードに障害が発生した場合やメンテナンスに備えています。

最後に

まずTEEの本番稼働というチャレンジングな経験ができたことは、チームとしても大きな財産です。そして、今回紹介したkey-vaultによる秘密鍵バックアップは、あくまでTEEの本番適用で出てきた課題の一つです。他にも度々話題に上がるIntel SGXのEPCサイズ制限も涙なくしては語れません（つくば市様のWEBアンケートに向けては、負荷試験を実施し、キャパシティプラニングをした上で臨んでいます）。このように様々な難しさがあるIntel SGXを本番環境で稼働させる実績が積めたことは、これからのAnonify・秘匿化技術に向けた意義深い一歩だと感じています。

今回お話したようなm-TLSのお話だけでなく、実際にサンプルコードを動かすことができるAnonify解体新書もチームメンバーがscrapboxで執筆しています。私も隔週で計算機科学やプライバシー技術の論文紹介をしています。そして、難しい秘匿化技術やプライバシー技術を社会に実装していくには、技術視点だけでなく、Biz視点も車の両輪のように重要です。LayerX Labs Newsletterでは毎週Biz/Techの両面から執筆していますので、ぜひ以下からご購読ください。なんと無料です。

https://layerxnews.substack.com/