2020年3月21日土曜日

BI-SGX開発＆SGXとの戦闘記録（前編）

2019年度未踏IT人材発掘・育成事業に「生命情報解析向けインタプリタを搭載した秘密計算用クラウド」のテーマで採択されておりましたaosでございます。


未踏の元でプロジェクトを進めて行った時の所感は別の記事に譲るとして、本記事ではプロジェクトにて開発したプロダクト「BI-SGX」のカジュアルな説明や、因縁の宿敵頼もしいハードウェア支援セキュリティ技術であるIntel SGXとの戦闘履歴を書き連ねていきます。


BI-SGX開発の背景と目的

最近では当たり前のようにクラウドが普及しており、かつ特に大手の提供するクラウドは各企業が十二分に厳重なセキュリティを担保した状態で提供してくれています。しかし、それらはあくまでもブラックボックス的なものであり、より客観的にセキュリティを担保出来る手法を用いて、機密性の高いデータを使用しながらの計算を行いたい、というニーズがあります。


この、「データを保護したまま計算を行い、使用した各データを特定できない形の結果を得る」、ような技術を「秘密計算」と呼びます。


最も有名かつ直感的にわかりやすい秘密計算技術が「準同型暗号」です。準同型暗号とは、暗号化された状態で加算や乗算に相当する演算を行い、復号するとちゃんと実行した加算や乗算の結果が取り出せる、という凄い暗号です。特に、準同型暗号の中でもより強力な「完全準同型暗号」は、加算と乗算両方を行う事が出来ます。


この完全準同型暗号は非常に魅力的で、これさえあれば様々な秘密計算モデルに応用する事の出来る夢のような技術です。しかし、完全準同型暗号には致命的な欠点があります。それは、あまりにも重すぎるという点です。


通常のCプログラムで1+1を1億回繰り返すと、（当方の環境では）0.1秒ほどかかりますが、HElibという完全準同型暗号を用いると、1+1を100万回で110秒ほどかかります。


流石に遅すぎる


この通り、私の生まれた時代のコンピュータサイエンスは、準同型暗号の持つ偉大な力を活かしきれる段階には到底及んでいない、という壁にブチ当たり、泣く泣く準同型暗号の活用をまずは諦めました（ちなみに、他の秘密計算技術である「秘密分散」と準同型暗号を組み合わせた「Homomorphic Secret Sharing」という技術は、両者の欠点を打ち消し合い大分速いので、興味のある方は検索してみて下さい）。


この状況で目をつけたのが、「Trusted Execution Environment（TEE；信頼可能な実行環境）」という技術です。TEEは、ハードウェア支援によりRAM上に保護領域を生成し、そこにデータを置くことで、データを保護しながらプログラムを実行する事を可能にする技術です。このTEEを実現したプロダクトとして、天下のCPUメーカーであるIntel社が、Skylakeアーキテクチャ以降のCPUにある拡張機能を搭載しました。


そう、それこそが


あのクソ忌々しい
正気の設計とは思えない
設計開発者を3000時間くらい拷問したくなるような

我らが天啓・Intel SGX（Software Guard Extension）


だったわけです。


SGXの詳細な説明は、自著のQiita記事をお読み頂ければと思いますが、要するにCPU内の「MEE（Memory Encryption Engine；メモリ暗号化エンジン）」というメモリコントローラを拡張したユニットによって、「Enclave」と呼ばれる保護領域をRAM上に生成する事で、TEEの要件を満たす事の出来るような仕組みです。


SGXはAESベースで動いている為、準同型暗号とは異なり平文同等の速度で演算する事ができ、かつ完全性検証や再生攻撃対策等も実現している為、理論的には非常に高セキュリティかつ高速なTEEを実現する事が出来ます。


なので、「SGXをクラウド上で動かせば、（Intelのハードウェアさえ信じれば）十分客観的にセキュリティを担保できる秘密計算と同等の機能を提供できるクラウドを開発できるのでは？」と考える人間が出てくるわけです。その一つが、川崎病という難病の原因遺伝子を特定する為に、患者やその近縁者の遺伝子情報を用いて演算を行うクラウドシステム「PRINCESS」です。


私もこれを受けて、より汎用的な用途・利用方法でSGXの保護機能を利用できるクラウドシステムを開発したい、と考えました。これが実にM0の時でした。しかし、ここで私は以降3年近く地獄の底に突き落とされ、精神をズタボロにされながら開発を進める羽目に遭う、SGXの真の恐ろしさに直面するわけです……（ここからしばらくBI-SGXから脱線してひたすらSGXに暴言を吐きます）


導入の時点で漂う「嫌な予感」

早速SGXを利用するべく、Ubuntu環境にSGXを構築しようとするのですが、その時点で尋常とは思えない「不親切さ」を感じるわけです。Readmeの手順通りやれば面倒臭いものの一応詰まらずには導入を進められるのですが、一つかなり躓いた部分がありました。それは、今では廃止されましたが、当時（SGXのバージョンが1.xだった時代）は、iCLS Clientというものをインストールする必要があり、そのインストーラをダウンロードページとしてIntelに提示されていたリンクがリンク切れを起こしていました。


更に、結局Google検索で当該ページを見つけても、やたらに長ったらしい入力を要求され、悪戦苦闘の果てにやっと導入に成功した、という感じです。


これが例えば個人が提供しているサイトなら良いんですが、あの大手も大手のIntelがこの調子とか、「え、大丈夫か？」と素直に思ったのは今でも覚えています。


脆すぎるSGXドライバ&無能すぎる公式フォーラムのアドバイザ

SGXを利用するにあたっては、SGXドライバと言うものを導入する必要があります。この導入自体は簡単なのですが、問題は導入後にあります。


ある日、SGXプログラムをビルドまたは実行しようとすると、「0x2006」というエラーコードが表示され、異常終了しました。一体何事だ？と思い、すぐ検索するのですが、Intelの公式フォーラムでは「SGXSDK（コイツへの暴言は後でたっぷり書きます）が導入されていない可能性があります」「BIOSで有効化していますか？」という回答が書かれているにとどまっていました。


やってるに決まってんだろボケ


では結局何故このような不具合が起きるかと言うと、どうもArchitectural EnclaveというSGXが内部で利用する特殊なEnclaveを司るaesmdというサービスが、再起動するとブッ壊れて再起不能になる、という、80億年前のコンピュータもビックリ仰天なわけのわからん不具合を抱えているせいなのでした。


これを直すには、この現象が発生する度にドライバをリインストールする必要があります。かつ、何故かビルドしてから一定期間経ったSGXドライバのインストーラは、途中でエラーを吐いてインストールに失敗するので、結局その度に
  1. SGXドライバをアンインストール
  2. SGXドライバのインストーラをビルド
  3. SGXドライバをインストール
する必要があるわけです。Intelさぁ……


これは自分の勝手な憶測なんですが、これに関してはIntel側がセキュリティ面か何かに過剰に警戒して、インストールしてから一定期間経ったSGXドライバを意図的に消し飛ばす自爆装置を搭載しているのではないか、と考えています。再起動すると毎回不能になるわけではなく、ある程度インストールから時間が経ってからこの不具合が発生するので、私はこのような見解を持っています。メンテナンス面倒臭すぎんだろこの糞システム


Enclaveのサイズ制限

これはSGXに手を出す段階で分かっていたのですが、Enclaveは上限96MBという苛烈なサイズ制限を要求してきます。後発のSGX2では、現実的でないレベルにごく一部のマシンのみが動的にEnclave（正確にはEnclaveの中核であるEPCのページ）を拡張していく機能があったりしますが、現実問題を考えると、まあやむを得ずこれには従うしか無いわけです。


で、「何で96MBなの？」って疑問が浮かぶんですが、唯一発見できたIntelによる見解が「TCB（Trusted Computing Base；信頼可能な計算ベース。TEEよりもより狭義な意味合いで使われる印象があり、SGXならEnclaveそのもの）の面積は大きいとセキュリティ上のリスクが増えます（根拠となる理由の説明無し）」


なぜ？？？


Intel「我々の研究により、96MBがセキュリティ上最適なサイズだと結論されました」


は？？？


いや技術屋ならその論拠示せよ、とマジで思うんですが、恐ろしいのはこの事実は公式フォーラムにしか書かれていない、という点なのです。Intelから発行されている、Intel SGX explainedという、最も原理に近い所を説明してくれている文献にすらこれらの論拠は書かれていません。マジで大丈夫かよSGX……


この点、準同型暗号が素晴らしいのは、この手の不信感を一切抱かずに秘密計算が出来る事なんですね。SGXも既存のクラウドよりはホワイトボックス的なセキュリティを実現できるとは言え、当然IntelやIntelのハードウェアは信用しなければなりません。しかも、ハードウェアに関してはSGXpectureのように、普通にヤバいレベルまで陥落しかけた事もあります。また、民間企業であるIntelを信用しなければならない以上、例えばSGXの軍事利用は到底厳しいでしょう。


なので、本当に出来れば準同型暗号を使いたかったし、ここまでに挙げたSGXのヤバい側面の時点で割と後悔していたのですが、実用性を選んでしまった以上もう突き進むしかありません。


SGX公式開発ライブラリ（SGXSDK）とSGXの裏仕様



お前だよお前


私がSGXプログラムを開発する上で地獄を見た最たる原因の一つがこれです。ちなみにもう一つは後述のIntelが提供しやがったてくれたコードの怪奇極まりない設計です。


SGXの機能を利用したプログラムを開発する上では、SGXSDKと呼ばれる公式の開発ライブラリを利用しなければなりません。で、この厳しい制限の付いたゲテモノC/C++を駆使してSGXプログラムを開発する為のSGXSDKなのですが、とにかくマジで酷いです。どれくらいかと言うと、SGXを利用したシステムの論文で公然と罵倒されるレベルに酷いんです。より詳しく言うと、SGXSDKが課してくる地獄のような制限と、C/C++という今の時代お世辞にも高級とは言えない（であろう）言語が組み合わさる事により、開発者に猛烈な負担をかけてくるのです。


例えばSGXElideというシステムの論文では、元々412行の普通のプログラムをSGXSDKを用いてSGX化した所、3523行にまで肥大化したと報告しています。また、同論文では「最もクソみたいに面倒な作業は、我々のSGXElideの導入ではなく、SGXSDKを用いたプログラムの開発そのものである（The most tedious work lies in creating the SGX programs themselves.）」とまで言及されており、どれだけSGXSDKがヤバいのか少しは想像が付いたと思います。


では、SGXSDKのクソな部分をそれぞれ見ていきましょう。



サンプルの意味を為していないサンプルコード

まずSGX初心者が躓くのはこれではないでしょうか。この内、SampleEnclaveという最も初歩的なものは、開発者リファレンスを片手に解読すればまあ分かるのですが、問題はそれ以外です。


例えば、SGXにはLocal Attestation（LA）という手続きが存在し、これは同一マシン上のEnclave同士でお互いにお互いの正当性・完全性を検証して、鍵交換の後にデータをやり取りするプロトコルです。


で、これのサンプルコードも存在するのですが、例えばmsg3というコンテキスト（マニアックな話をすると、LAのチャレンジリクエストを受理した側のEnclaveのREPORT構造体）を処理する1関数だけを見ても、
  • sgx_dh_initiator_proc_msg3()という形で呼ばれている
  • 実はsgx_dh_initiator_proc_msg3()は#defineによってマクロ付けされたものであり、実体はsgx_LAv2_initiator_proc_msg3()である
  • 更に、sgx_LAv2_initiator_proc_msg3()は何とdh_initiator_proc_msg3()のラッパー関数なので、真の実体はdh_initiator_proc_msg3()に存在する
という感じです。


テメェサンプルコードだよな？？？


何と言うんでしょう、普通サンプルコードっていうと、初心者でも実装や設計の仕方がわかりやすいように書くものだと思っていたのですが、流石シリコンバレー、凡人とは格が違いますね笑笑


ふざけんじゃねぇぞCPU野郎


という感じで、まだ触れていないSGXの機能に触れようとする度に、HPを99%削られる凶悪な敷居の高さが、SGXが敬遠される大きな理由の一つだと私は強く信じております。



ヤバすぎるMakefile

SGXに手を付けた人間が、自作のSGXプログラムを作りたい！と考えた場合に次に躓くのが恐らくここです。そう、SGXのMakefile、かなりヤバいです。勿論、SGXでない他のシステムにももっとヤバいのはあるのでしょうが、少なくとも準同型暗号ライブラリであるHElibはこんな恐ろしいMakefileの記述は要求してきません。


SGXアプリケーションは、非信頼部分（Enclave外で動作する部分）と信頼部分（Enclave内で動作する部分）から成り立っており、まずこの時点で少なくとも2つのビルドが発生します。


更に、Enclave内で動作するプログラムは、
  1. edger8rというツールでEnclave境界を跨ぐ関数の関数宣言をSGX語（Cのガワを被った怪文書です）に翻訳
  2. SGXライブラリも交えながらオブジェクトファイルを生成（Enclave.o等）
  3. オブジェクトファイルをリンクし共有ライブラリを生成（Enclave.so）
  4. sgx_signツールを使用し、共有ライブラリにRSA 3072bit秘密鍵で署名（Enclave.signed.so）
のように、デプロイ可能な形にするまでかなり手間がかかります。ですので、これを全て実行するMakefileを書くと、以下のようになります（Makefileのごく一部です）：


キモ……(素)


勿論この世の中凄い開発者が多いですし、私はそんなにプログラム強くないので、こんなん余裕でしょ、って人もいると思います。ただ、少なくとも私はこんなん絶対書きたくありません。


なので、皆さんがSGXプログラムを作る時は、IntelのSampleEnclaveのMakefileを丸ごとパクって下さい。もし追加でソースファイルやライブラリが必要になっても、追記くらいならMakefileの書き方さえ少し解読すれば出来るのでオススメです。また、後述のRemote Attestationを利用するSGXプログラムを作る上で、Intelのソースコードを流用する場合は、Autotoolsを利用してMakefileに定めたい要件を簡単に記述できるので、大分楽になります。なお、Makefileの書き方全く詳しくないのは完全に私の落ち度です。


OSを信頼していないSGXの宿命

SGXは、OSやハイパーバイザからもデータを保護出来る、という頑強さを売りにしています。一見かなり聞こえは良いんですが、実はこの仕様が開発者に酷い負担を強いるのです。


OSを信用しない、という事は、Enclave内ではOSに権限のある操作を一切使用できない事を意味します。つまり、Enclave内ではシステムコールが発行される関数が軒並み使えない事になります（例：fork, exec, printf, scanf, exit, fopen, rand, time, setlocale）。


また、これだけではなく、C++でファイルや文字列等の操作をする上での生命線であるstreamは全て使えませんし、またメルセンヌ・ツイスタ等の乱数生成器を用いた一様分布乱数を生成する為の関数uniform_real_distribution<>()関数のように、何故使えないのかよくわからない関数が無効化されていたりと、とにかくカオスです（ちなみにC++11に対応していないだけかと思ったら、vectorのemplace_back()は使えたり、本当に謎です）。


なので、開発者は常に開発者リファレンスのC/C++非対応関数リストと穴が空くまで睨み合い、常に「この関数は使えないかも知れない……」という恐怖に追われつつ、手探りでプログラムを開発していかねばならないのです。


これを軽減する為に、Enclave内からEnclave外の関数を呼び出すOCALLという機能が提供されていますが、これも実は後述のEDLという形で開発者に牙を剥いてきます。


無駄すぎる独自のtypedef

突然ですが、以下の仰々しい文字列を御覧下さい。
  • sgx_isv_svn_t
  • sgx_prod_id_t
  • sgx_spinlock_t
  • sgx_misc_select_t
  • sgx_ra_context_t
  • sgx_enclave_id_t
  • sgx_time_t
これらは、SGXがtypedefで定義している独自の型なのですが、ここで問題です：この内、整数型である型はどれでしょうか？



答え：全部



いや、分かりますよ、「それぞれ特定の部分において使われるので識別しておく意味がある」、という意見もあります。しかも整数と言っても、厳密にはshortだったりlongだったりするのもあります。


しかしですよ、このクソみたいに見慣れない型の実体を操作しなければならない状況に開発者が陥って、「この型何なんだろうなぁ」思って350ページ以上もあるリファレンスを漁って調べたら、「typedef int sgx_ra_context_t;」と出てきた時の気持ちを考えてみて下さい。


ブチのめすぞCPU野郎


他にも、sgx_ra_key_128_tとsgx_key_128bit_tという、どっちも実体がuint8_t[16]である本当に分ける意味のわからない型も存在して（そんなにRA向けである事を厳格に宣言する必要があんのか！おいIntel！お前に聞いてんだよ！）、疲弊し尽くす事間違いないでしょう。


気が狂ってるとしか思えないSGXAPI

出ました。最凶最悪の問題児です。


例えばEnclaveを生成したり、Enclave内で暗号処理したり、といったSGXに密接に関わる処理は、SGXSDKの提供するAPIを使用して定義する必要があります。


もう何もかも酷すぎて、全部列挙するとGoogleが保有する全てのストレージを埋め尽くしてしまうレベルで書き散らせてしまうのですが、ここでは掻い摘んで説明しましょう。


まず、Enclaveを生成する際には、sgx_create_enclave()というAPIを使用します。この時、起動トークンと呼ばれる、sgx_launch_token_tと型付けされたuint8_tの塊を与えるように指定されます。


これ、Launching Enclave（LE）と呼ばれるArchitectural Enclaveを経由し、しかもEINITTOKEN構造体と呼ばれる形で如何にもEnclaveの重要な構成要素として使命を果たしているように見えるんです。


しかしこれ、マジでいらないんです。


ええ、Intel曰く「起動トークンはある署名済みEnclave共有ライブラリから初めて生成された時に保存して、次回同じ共有ライブラリから起動する時に高速化出来る」、と書かれているのですが、


マジで全く変わりません。


なので、全くいらねぇ要素の為に、0で埋め尽くしたダミーのsgx_launch_token_tを渡し、毎回起動トークンを生成させてそれを破棄する、という、マジでバカみたいな処理をしなければなりません。


極めつけは、SGXが出て割と初期に書かれたIntel SGX explainedのホワイトペーパーにおいて、「LEはシステムソフトウェアで十分代替可能なので、そもそも起動トークンどころかLEがいらねぇ」と書いてあるんです。


だったら何故初期に直さなかった


もうここまで年数経ってしまったら後の祭りです。互換性問題が出てくるので二度と修正できないでしょう。バーカ笑


2つ目に、とんでもないものをお見せしましょう。



画像の示す通り、シーリング（Enclaveまたは署名鍵固有のハッシュ値によって生成されたコンテキストを用いた暗号化処理）とアンシーリング（同じく復号処理）の利用例なんですが、赤い四角と青い四角を見て下さい。これ、青がAES/GCMにおける任意で指定できるMAC（メッセージ認証符号）で、赤がそのサイズなんです。お気付きですか？


当たり前のように順序が逆


私、最初これを見た時は衝撃を受けました。というかそもそも、シーリングでは追加のMAC情報群（赤と青の四角）が先頭に来ているのに、アンシーリングでは暗号文が先頭に来ています。


Intel、本当に大丈夫ですか？？？設計者、ヤクでもキメながら設計しませんでしたか？？？また、この正気を疑う設計をチェックする人間、社内に一人たりともいなかったのですか？？？


と、アメリカの闇を感じられる恐ろしいSGXAPIのご紹介でした。


最後に、純粋に使う頻度が高い割に面倒臭い関数として、sgx_rijndael128GCM_encrypt()関数とsgx_rijndael128GCM_decrypt()関数をご紹介しましょう。まず命名へのツッコミですが、何故rijndaelにしたのでしょうか？rijndaelって呼び方はAES暗号の古い呼び方なので、SGXの時代にはとうにAESとして普及しているはずなんですが、マジでIntelに何が起きたんでしょうか？？？


それは別として、この関数は鍵・初期化ベクトル・GCMタグ（MAC）・暗号文・平文全てuint8_tの配列で全て操作しなければならない（GCMタグに関してはsgx_aes_gcm_128bit_tag_tと、またいりもしねぇ型付けがされていますが）ので、純粋にハゲます。どっかでミスって1バイトずれただけで終わるので、結構シビアです。それが送信側での処理に問題があった、なんてなると、もうデバッグだけで全身が痙攣し始めてしまいます。


CIAの拷問に利用されていると有名な境界定義言語（EDL）

さて、SGXではEnclaveの境界を跨ぐ関数呼び出し（即ちECALL及びOCALL）には、EDLという形式で別個追加情報を設定する必要があります。


EDLは、C/C++の関数宣言を拡張したみたいな書き方で記述し、渡すバッファのポインタ方向（渡した先へ渡すのか、あるいは渡した先から持ってくるのか）や、渡すバッファの厳密なサイズの指定等を行います。ここで、実際にBI-SGXの開発において記述したEDLのごく一部をお見せ致します。


キモ……(2回目)


このように、たかだかEnclave外のDBに暗号データをストアするだけで、恐ろしい量の引数と追加設定の記述を強いられるのです。しかも、受け渡しするバッファのサイズは厳密に指定されていなければならないので、例えばEnclave外のDBからデータを持ってくる場合、一度別の関数でDBからフェッチしたデータのサイズを取得してから、そのサイズを指定して実データを持ってくる、といったような気が狂った作業を要求されます。


char型の配列であり、ヌル終端されている場合のみstringというオプションで自動的に長さを決定できますが、SGXでは大体乱雑な暗号文を扱う為、ほぼ役に立ちません。


境界を跨いだデータ受け渡しにおける「裏仕様」

普通、ヒープは当然スタックとは別物ですので、ヒープでスタックサイズ上限（通常初期状態では約8MB）を超えるサイズを関数呼び出し時に渡しても、勿論エラーは出ません。よって、私も20MBの暗号化したデータをEnclaveに入れようとするんですが、どうも関数呼び出しのごく直後にクラッシュするみたいです。


ここで知った恐ろしい事実なのですが、実はSGX、ヒープであろうが内部で特殊なスタック（強制で上限約8MB）を経由してEnclave境界を跨ぐので、ヒープであろうとこのスタックサイズ上限を突破できない、という気が狂った裏仕様が存在するのです。


このスタックサイズ上限は、Enclave設定用XMLや、勿論ulimit等でも変更不可能なので、折角のヒープなのに細々とした受け渡ししか出来ない事になります。しかもこれ、開発者リファレンスには一切書かれていません。


おいIntel！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！


流石にこれは当時ブチギレてた記憶があります。こういう事を平気で出来てしまうのが我々のIntel、天下のIntel。いやぁ、脱帽です笑


このクソIntel野郎！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！


リモート・アテステーションとIntelの書いたコード

SGXアプリケーションを作る上でのラスボスと言いますと、やはりRemote Attestation（RA）でしょう。詳しくはこちらのQiita記事で解説していますが、これがまたとんでもない実装難易度をしております。


軽くRAの概要を説明すると、遠隔からEnclaveを利用する時に、その遠隔のユーザが
  • 相手とするSGXマシンのCPUはIntelに正式に認められた正当なCPUなのか？
  • 相手とするEnclaveの完全性と正当性は保たれているか？
を検証し、同時にTLS通信用の鍵交換を行うプロトコルです。


で、普通の神経をしていたら、接続情報を指定して特定のAPIを呼び出したら、後は勝手に完了してくれるような設計をするはずです。しかし皆さん、忘れてはいけません。


Intelはまともではないのです


あろう事か、IntelはRAでやり取りされる情報msg0, msg1, msg2, msg3, msg4用全てそれぞれバラバラにAPIを用意し、しかもAPIを利用した上で半分以上自前でRAのプロトコル要件を満たす為の実装をしなければならない、という、人類が誕生して以来この世に存在してきたあらゆる暴君ですら泣いて逃げ出すような残虐な仕打ちを強制してきます。


M0の時代にRAを実装しようとして、あまりの難易度の高さに絶望し、その上指導教員に「君のシステムには合理性がないね」と言われ、夜寝ている間に金縛りに遭って目の前にEnclaveを模した四角とデータが現れ、データに「俺をEnclaveに入れろ……」とひたすら脅迫されまくったのは今でも鮮烈に記憶しています（※マジです）。


ただ、sgx-ra-sampleというIntelによって公開されているRAのサンプルコードを用いると、大分楽になります。というか、これをベースにせずに自前でRAを実装するのは超人レベルじゃないと不可能だと思います。


また、このsgx-ra-sampleで通信関数として用意されているmsgio、マジモンのポンコツです。


まず、全く必要ないのに送受信時に何故かhexエンコード/デコードをしているせいで、たった8MBの受信に10分かかるとか言う、小1のガキ時代の私（※50m走13.7秒）も驚愕の凄まじい低パフォーマンスを記録してくれます。


また、工夫をしないと発生するはずのないノイズがランダムに受信データの末尾に付着し、受信したファイルが復号できない、といったアクシデントも多発します。これに関しては、BI-SGXのリポジトリで修正したものを提供していますので、こんなヤバい仕様に直面したくない方は是非ご利用下さい。


BI-SGXの開発の決意

いかがでしたか？(クソバイラルメディア風)


これまでに無いレベルでSGXのヤベー所をぶち撒けましたが、これを読んで「あ、私もSGX開発してみたい！」とお考えになった方はいらっしゃるでしょうか？


もしいたら病的なドMです


私はこのSGXという、「便利な技術」の皮を被ったド畜生の残虐さを目の当たりにして、強い憤りを覚えました。実用性という意味では性能としてはかなりのポテンシャルを秘めているのに、あまりにも難解すぎて全く普及しない。そんなクソみたいな技術目の前にしたら


ブチのめしたくなりません？


という事で、私はSGXの高パフォーマンスなセキュリティ機能の恩恵は受けつつも、上述のクソみたいなSGXSDKの仕様・制約に縛られず、誰でも簡単にデータを保護しながらの処理が出来るクラウドを作る事にしました。BI-SGXの開発はそのまま大学院の研究としても流用していたので、建前上は専攻分野である生命情報解析の為の安全なクラウドの実現、も謳っていましたが、このSGXに対する怒りがBI-SGXの開発を始めた最も大きな理由です。



次回の後編では、BI-SGXの各コンポネントを、開発日記じみたのを交えながらご紹介したり、BI-SGXの小ネタを披露しようと思います。
投稿者 時刻: