こんにちは 本日はディスクファイブキーストーンとアームトラストゾーンで ティープトラステットエキゼクジュエンバーレメントプロビジョニングの開発についてお話いたします以前ディスクファイブグローバルサミットで似たような内容をお話しいたしましたが 本日はそれに加えて最新の更新状況また前回は全て英語でしたが 本日は日本語でお話しいたしますそれでは本日は te とトラステットアプリケーションのご紹介からお話しいたします そしてリスクファイブ cpu で te をとのように実現するかその次にはティープというプロトコルですが こちらはインターネット標準化団体の ietf で議論と企画家が進んでおりますこちらの概要について簡単にご紹介いたします そしてアームノコアテックス a でのティープの実装についてお話ししてその次にリスクファイブで実装がどのように今開発が進んでいるかっていうお話をいたしますまた 前回のリスクファイブグローバルサミットでお話ししながった今の ietf でティープの議論がどのようになっているかっていう状況をお話しいたします そして実際にティープのメッセージっていうのはどんなもんなってるか例をお話しいたします それでは te の言葉の定義からお話しいたしますいろいろなデバイスでクリティカルアプリケーション 重要なアプリのことですが詳細についた後ろのスライドで説明いたしますがクリティカルアプリケーションをデバイスで実行する上で ハードヤーまたはソフトヤーのセキュリティの脆弱性から守ろうという形がもともとの基本コンセントですそれをどうやって守るかということなのですが 現在の os とハードヤーは機能または高速化のために非常に複雑化しておりますのでそこの部分から分けて アイソデートってこと単語が出てますが分けてパーティションを聴いてセキュアワールドという区切ったところでクリティカルアプリケーションを実行するというのが te の言葉の定義ですでクリティカルアプリケーションはトラステットアプリケーション まとはエンクレーブと呼ばれることが多いですエンクレーバーどちらかと言うとインテル cpu で使われる言葉でトラステットアプリケーションどちらかというアームの cpu で使われることが多いという印象です 今現在あるハードヤーでどんなものがあるかということでインテル sgx amdseb アームトラストゾーンディスクファイブの p mp っていう機能細かい話は後ろのスライドでお話しいたしますが t を実現するための機能がハードヤーに入ってきている状況です先ほどクリティカルアプリケーションという単語が出ておりましたが実際どういうものかというと支払い関係のアプリ例えばクレジットカードまた何とかペー またはコンテンツ保護がかかったビデオまた音声のファイルの再生または認証が必要なアプリ例えばメールですとか個人情報が取り扱うデータを使うアプリですこちらをどういうふうに実行するかと実際には t というしてはハードヤーとソフトヤーの両方が必要になっておりますハードヤーの方は cpu が先ほどパーティションとお話ししましたが今動いてるos また今動いてる環境から別パーティションでプログラムを走らせるという機能が必要ですこちらをハードアシステッドアイソデー テッドエクゼギーションバイドメントという単語でご紹介されたりいたしますソフトヤーの方はそのちっちゃいちっちゃいがどうか別としてソフトヤーはアイソデートされた方で実行されるために何かしら実行環境が必要ですですのでこの2つは合わせて t という機能が実現されておりますそれではリスクファイブで t がどのようなものがあるかという列挙になります まずx 5社によるマルチゾンmit によるサンクタム グラーツ効果大学によるティンバー xmit による m i 6 こちらは別サンクタムと別のチームですで uc バークレーによるキーストンっていうのが代表的なものがございます こちらが発表されてたり実装が進むものでなりますこの中で我々はプロジェクトとしてキーストンをベースにその上に ティープを結局開発を行いましたその理由なんですがキーストンプロジェクトはオープンソースプロジェクトで開発が活発であったこと全てのオープンソースプロジェクトが開発が活発なわけではございませんので開発が活発であったかどうかということとオープンソースのライセスがどうなっているかっていうところは大事なポイントでしたであともう一つ我々の使い方ではどうしてもディナックスのようにm mu を必要とするということでしたあともう一つは設計が コンポーネントモジュールごとに機能を追加できるという形になっているということが用意としてありましたそれではこちらは t をリスクファイブでどのように実装がされているか具体的にはちょっとキーストーンがどのように実装されているかという形のご紹介をいたします左側は リスクファイブの電源が入ってから t a またはエンクレイブはどのように起動するかの流れになります一番最初は電源が入りますと zsb l まロムですブートロムそれから フラッシュに大体入ってる fsb lそれからセキュアモニターセキュアモニターはリナックスとか汎用 os と t の間の端渡しをするソフト屋のモジュールになりますでここら辺は一番上の特見命令で動いておりましてでその後リナックス側 ブートローラーとリナックスが起動してそこからta を実行するアクライアントアプリがこの例では2つ実行されています ですのでここからエンクレイブのトラステットホストアプリが1個1個右側の t の中でエンクレイブトラステットアプリを実行しているという形の流れになっています で実際にリナックス側のユーザーモードのアプリから t のアプリを実行したりまたは戻ってきたりするのはセキュアモニターを通して行われます右側の方は複数の t a 感とリナックスが動いているところどうやってセキュリティを担保しているかという形を説明した n になりますでリスクファイブネ p mp ってエントリーが8以上または16個まであります 一つの p mp エントリーはどのようになっているかというと自分の指定された目物理アドレスの長しかアクセスできないように指定がされております ですのでトラスセットアプリ1ってなっているピンクの領域は自分の範囲してされたアドレスしかアクセスできず トラスセットアプリにの領域はアクセスできないでまた青のリナックスの部分に割り当たれた部分はピンクの部分にはアクセスできないというような形をハード的に cpu が物理アドレスを分離しているという形になっております ですのでお互いにリナックスとラステットアプリ1のメモリーを読めないですしトラスセットアプリ中はトラスセットアプリ2のメモリー領域を読めないという形になっております本当はこんなに簡単じゃないんですがものすごく簡単単純化しますとこのような説明になりますそうではトラステットアプリケーションの実際の使われ方ユースケースについてお話いたします実際に使われたデバイスというのはこのように既に存在しますので開発に関わったことある人は少し知ってたりまたはある程度知ってたりすると思いますが改めてご紹介いたします大きく分けるとエッジデバイスまたは端末という形ともう一つはデータセンターという形になりますですのでデバイスっていう方はスマートフォン iot エッジデバイス具体的にナスですとかエッジのルーターですとかワイファイルーターですとか自動車の情報端末ですとかダッシュボードの真ん中にあるやつですねあとケーブルテレビの中のセットトップボックスまたは dvd プレイヤーレコーダーなどもが入りますし監視カメラまたは複合機の大きいプリンターみたいな時はいになりますあとデータセンターでは仮想化してたくさんの os を走らせるという用途がほとんどになってきてますのでそこでのゲスト os を守るというような形で使われてきていますで実際のアプリはどんなものかというと先ほどもお話ししたようにクレジットカードまあなんとかペイとまたはネットフリックスケーブルテーブル または電話の端末または車または保険会社またセキュリティ会社の端末という形になっておりますであともう一つよく使われるのはファーメアのアップデート ここでトラスセットアプリケーションフロムタムサーバーってありますがこのタムサーバーってのはちょっと後のティープの方の説明でお話しあとは最近はデータセンターで皆さんがサービスを申し込んで自分のゲスト os でよくあるパターンですワードプレスのようなウェブサーバーを使ったり設定したりいたしますが最近はお客さんがクラウドサーバーの業者が自分たちの os を読めるのを言い上がるようになっておりますのでt っていう技術を使ってクラウドサービスを提供しているベンダーであっても自分のゲスト os の中身は技術的に読めないっていううちに技術的に保証されているっていうのを要求するようになっております今回のスライドではあんまりそちらの方の説明いたしませんがこちらは今後重要性が増していく分野だと思われますここらへんから後で説明するt プがどうして必要性があるかというような説明になりますでトラスセットアプリケーションが端末で単独で動いてるだけであれば それほど困らないです昔から出荷前にトラスセットアプリケーションインストールして出荷してその製品寿命が終わるまで使い切っていただくいう形であればある程度すでに実装はされておりました ただし現在ほぼすべての端末またはデータセンターも含めてネットワークに接続して使用するちになりますので先ほどニュースケースの大半はデバイスとサーバーと通信しながら仕事をするかになっております ですのでセキュリティアップデートまたは機能が追加されたまたは新しい端末に自分たちのアプリケーションを入れたいというが出てきましたのでそれをインターネットとデバイス側で強調してインストールアップデートデリートができるようにするという形になってきてこれをインターネット標準化団体の ietf でt プワーキングループで今現在企画を策定中です はいでこちらはティープワーキングループでのティープのドラフトからの3つの文章の抜粋ですで具体的に上からトラッセットアプリケーションちょっと長いので次から略してt a って呼びますが t a のライフサイクルの管理具体的にはインストールデリートができるようにまたアップデートができるようなことですこの t a は改ざんすることができないまた改ざんされたら禁止できるようにっていう機能が必要です そしてこの t a のユースケースとしてはクリティカードアプリケーションっていう言葉が使われておりましたがセキュリティセンシティブな操作オペレーションまたはそのようなセキュリティにセンシティブなデータを扱うようなアプリという形になります それは今度はt プをどうしてみんなで使わなきゃいけないかどうして企画化しなきゃいけないかという話になります端末を1つを1複数の業者がトラッセットアプリをインストードして 動作させたいという用途が多くなってきました例えばスマホ1つの端末になんとかペーだったり動画配信だったりのアプリを使う または家庭に置いてある情報端末また車の中にあるデバイスで複数の保険会社または複数の動画配信会社または複数のサービスベンダーがアプリをインストールして使わないといけない まさ使うようになると便利であるということになってきましたのでt プできちっとお互いベンダー8ベンダービーが思ってる t a 1とt a 2がお互い信用できる形で管理できるというところをt プで担保しようというようになっておりますそしてスタイドの中で赤字になっているところですがこのような設計が行われることで端末側は t a の開発ベンダーとは別の会社であってまたはベンダーであっても独立してお互い開発は 進められるという形になりますここが企画化する非常に大きなメリットでありますそれではt プの間約化した概要素をもとに全体の動きをご紹介いたします まずサーバーとデバイスがありますサーバーの方はタムと呼ばれます t aマネジメントサーバーです デバイスの方は信用できないアントラッセット領域と信用できるトラッセットエリアがあります トラッセットエリアの方に t a 1とt a 2っていうのをタムサーバーの方からインストール実行削除ができるようにならないといけません プロプロトコル上は実全てデバイスの方がトリガーになってタムサーバーと問い合わせをして動く形になっているんですが今日の説明は説明を間約化させるためにサーバーの方が トリガーとして動いているかのようにちょっとお話しいたしますただ実際にデバイスの方が一発目のパケットを出す形です タムサーバーの方はどうやってt aを管理しているかとなりますがデバイスの方で信用できる領域にはt a 1t a 2っていうのが入るためにt プエージェントっていうものがございます 信用できないアントラッセットリアの方にはt a 1にとt a 2についになる端末アプリが入りますのでそれをがアップ1アップにっていう形で 寿司されておりますこちらはt プローカーっていうコンポーネントを通してタムサーバーと通信するという形になっておりますで実際にデバイスで必要な t a をどう管理するかって形をの手順ですがまず最初にアップ1アップにみたいな形のアプリを スマホのなんとかストアみたいな形かまたはユーザーがデバイスに直接 usb メモリカーリンストールするかまたはその デバイスの業者例えば車のリーダーだったりまたはセキュリティ監視カメラの運営会社がアプリをアプリ1とアプリになどを別々の会社が入れますアプリ1が例えばどっかの会社だったらアプリには別の会社という形になりますでそのアプリ1アプリ2がt プローカーとやりとる用してタムサーバーからt a 1 自分の担当する t a をダウンロードしてきて t プローカーがハードヤーを返してt プエージェントに連絡して t a をトラステットリアの方の t ガーにインストールするという形ですでそうした場合その後アップ1を起動すると t a 1 が実行されるそしてデバイスからこの t a はもう必要がないと必要がない理由はデバイスのユーザーが契約を終わりにしたとか またはタムサーバーの運営会社がもうこのデバイスはうちの管理ではございませんサービス終了しましたまたはセキュリティで更新でもうフロアプリ削除したいですとか言った場合は 先ほどの順番とまた同じですがt プローカーがタムサーバーとやり通りをしてハードヤーを通してt プエージェントがその t a を削除するという形になりますこちらのスライドが今日の本編のような形ですが実はt プの議論が itf で四方八方に散らばっておりまして中で内容をわかっている人でないとちょっとご紹介できないという状況になっております なのでちょっとここで大事なところなのでお話いたしますまずt プワーキングループっていうのが自分ところで単独でt プロの企画を作ってと議論と技術開発をしているかというとそういう形になっていないいうすごいところになっております なのでt プワーキングループ以外にスライドの右側のスートワーキングループとラッツワーキングループ3つのグワーキングループに間がかっておりますし ティープの中で左側のスライドに見えますと3ドラフトが3つ関係しているというすごい状況になっておりますこれがどういう関連しているかっていうのをお話しいたしますとタムサーバーとデバイス自体をやりとりはt プワーキングループが決めておりますところが t a っていうのは t a のバイナリーまたはデータですのでバイナリーのマニフェストは t スートワーキングループがフォーマットを決めておりますスートのマニフェストに従ってタムサーバーもデバイスも t a を識別できるバージョンも分かるという形になってで証明な先も分かるという形になっております ラッツワーキングループっていうのはデバイスから見たらタムサーバーが信用できないといけません でタムサーバーからしたらデバイスが信用できないといけませんなおかつ t a の開発ベンダーからすると t a が信用できないといけないという形になりますですのでそこらへんを リモートアテステーションのような形でお互い信用を担保するオーセンティケーションを行うっていう仕事の方法をラッツワーキングループで策定しております左側のスライドの黄色と青と緑の部分がビッツのドラフトありますがそれをどこを定義しているかとご紹介しますと t パークテクショドラフトっていうのは各コンポーネントの役割のみを例えばこのタムサーバー何をするものかどういうコンセプトで設計されて何を役割はどういうものだかそれをt プローカーも何をするかどういう役割で何ですかアップ1t プレイジュート t a 各コンポーネットの役割を定義しているというのがt パークテクショドラフトです青い部 t プロトコドラフトっていうのはt プローカーとタムサーバーの間の バイナリーのフォーマットまたメッセージのフォーマットを策定している規定しているという形になっておりますさらにややこしくしているのが実はそのt プのメッセージ自体はタムサーバーとt プローカーは一番今一番最初の実装ではhttp の tcp パゲットの上に乗せる形になってますのでその乗せ方を策定しているのがまた規定しているのがt プオバイチティっていうの緑のドラフトはいなのでこれ全体を知っていないとちょっと各ドラフトをお脳の自分で読み始めると何のことだか全くわからないっていう上下になっておりますがこのスライド1枚で全体を把握できると思いますそれでは一番最初にt プの実装を行ったアームコアタックスa での実装をお話しいたします基本的にt プは非対象アンゴーカールゴリズムを使っていますこの時はta を作るベンダーのことサービスプロバイダーという形で呼ばれておりましたこれ古いドラフトなので単語のがいくつか定義が言葉が違います例えばあと左下のotrp ブローカーっていうのを今げずはt プローカーですがotrp とt プの違いは次のスライドでお話しいたします古い単語でこのまま説明いたしますta の開発者開発ベンダーは有有 id と ta の公開会議ここで spi パブリック機になっていますがこれをtタムサーバーに預けておりますあとタムサーバーは自分で秘密影と公開会議を作成して自分は秘密会議を持っておりますデバイスの方はotrp ta 実際には今のプレジェントに相当するところがt プのルート証明書を持ってるという形になっておりますですのでどのように動くかって言いますとデバイスの方が ta クライアントというアプリをインストールされて起動すると自分の ta の有有 id sp ta ってなっていますが有有 id をt オーティアルピープローカーにあの連絡してotrp プローカーがタムサーバーとやり取りをしてタムサーバーはデバイスで必要とする ta のバイナリーをまず最初 ta の spa の公開会議で暗号化されて一般的な秘密会議を使って暗号化するんですがこのドラフトの時は公開会議を使って暗号化してタムサーバーの秘密会議で証明する その証明したバイナリーをhtp k でotrp プローカーに渡しますオーティアルピープローカーは実際の下回りのリナックスカーネルのドライバーと smc を通してハードウェアのサポートでセキュリティを担保してトラステットワールドの方に渡します オーティアルピーティアが実際に受け取ったバイナリーのタムのルート証明書で証明検証してきちっとしたタムから来たバイナルリアル化を検証してオッケーであってあれば spi の秘密会議 ta ベンダーが作った秘密会議で区合してきちっと複合できるかっていうのを確認してオッケーであれば ta は te の中でセキュアストレージに保存されるという形になりますt a クラ左側の t a クライアントが実際に支払いだとか動画を見るという形の場合になった時にセキュアストレージに保存されたta が実行されて終了するという形の手順です はいそれでは今度は リスクファイブでのティープの開発についてお話をいたしますほとんどコンポーネントの絵は一緒なんですがところどころ変わっているのはドラフトの子が更新されたっていうところとあと実際リスクファイブに合わせて 実装を行う上でマルキシスクラッチからやるわけではなくできるだけアームで実装した形の資産を活かす形でどう工夫したかというところがメインになりますなのでこの絵だけを見るととても前のスライドとよく似てます タムサーバーの方はセコムの方がタムサーバーをITFの場で参加してタムプロトをオープンソースがさしておりますギットハブにオープンソースになっている名前がタムプロという名前で公開されております デバイスの方ですが最新のティーププロトコルの名前になってティーププローカーアップとハローアップっていうのがリナックスの方でございます ティーの方こちらキーストーンを下回りで使ってるんですがティープエジェントティーとあとサンプルのハローティーっていうのがございます このハローティーまたティープエジェントティーっていうのはだいぶ前のスライドの方のハードヤーのPMPで守られているという形になっております 具体的な詳細に入る前にちょっと左側の上に書いてあるところですが 企画が変わるの中で議論が進んでティープブローカーとタムサーバーの間のやりとりがJSONベースからシーボアベースに変わりましたJSONっていうのはよくテキストベースで今のウェブブラウザーはその他でよく使われているのでご存知なことが多いと思いますがシーボアは何ぞやという形なんですが ASN1というような形でテキストとバイナリーをお互い変換するっていうようなフォーマットが規定されておりますがそれのもっと進化させた形のものがシーボアです本当はこんなに簡単な説明だと怒る人は異想ですがすごくわかりやすくお話しするとシーボアはテキストとバイナリーをお互いそう方向で変換するフォーマットです JSONの時はテキストフォーマットのままやりとりを呼びました ですのでタムプロットとタムティープブローカーの間のやりとりと安岡と署名もしたJSONのパケットサイズがMTを超えた1500超えてパケットが負荷2つに分かれるというようなことがございました シーボアの方はJSONと比較すると非常にメッセージサイズが小さくなりますTAのバイナリーを含まない場合はシーボアのメッセージのバイナリーは30バイトだとか40バイトだとかそういうサイズになります それではこれからデバイスの中でティープの実装の話になります本日のメインテーマであるところに車で迷気が非常に長くなりましたがやっとディスクファイブでTEがどういうふうに動くようにしているかというお話いたしますティープブローカーアップとティープエージェントTAっていうのがデバイスの中では非常に大事なコンポーネントになりますがそれが動くための下回りがARMとディスクファイブまたはインテルで違いますITFで企画策定している時に1特定のCPUでしか動かないような企画を作った場合どうしても世の中で使われないせっかく企画を作っても向かわれないという形になってしまいますので特定のCPUまたは特定の何かに依存しない形の設計にしてみんなが使える形にして初めてITFで議論しているメリットが出てきますその時にティープエージェントTA、ティープブローカーアップに相当するものを一度うちARMで作っておりますこれをできるだけディスクファイブまたはインテルでも動かそうという形を考えた場合にですねまずARMの場合オプティでTEを実現するソフトやスタックがございますこちらはグローバルプラットフォームAPIをオープンソースで実装した形になっていますグローバルプラットフォームAPIは各スマホで使われているAPIですのでそれを全く捨ててスクラッチで作るというのは研究開発スドガーも事業部だったとしてもまたはビジネススドガーだったとしてもあまり特策ではないというよりも全く特策ではなございませんなのでグローバルプラットフォームAPIをこちらで動くようにしようという形にしてここにつなっているハローTEとTEプレジェントTEの下にGPAPIという形の資格がありますがここがグローバルプラットAPIのサブセットを提供している形になりますもともとのグローバルプラットフォームAPIというのは比較表を見ていただくとわかりますが非常にAPIの数が多いです例えば200とか200以上ありますそれは過去の互換性をずっと維持しながらAPIを追加してきたからの歴史的背景があるわけですので新しくTープですとか新しくディスクファイブですとかって言った時に全てのAPIが必要かというと必要ではないです酸素権でハローTEって今ここでは書いてありますけど酸素権で持ってるTEだとか各決済会社だとかストリーミング会社が行っているTEの実装が全て200のAPI必要とするかというとそんなことはないです基本的にはTEをオープンして実行してクローズするみたいな形のAPI TA自体の管理するAPIと乱数ですとかハッシュ管数ですとか対象鍵案号のAPIですとか非対象鍵案号のAPIあとそれを使った署名の作成と署名の検証というようなAPIそれ以外にTA自体の秘密データの保存と読み書きという形になります大体30ぐらいのAPIを充実してキーストーンの上にラッパーをかけているという形を行っていますそれではもう一段深掘りしてお話しいたしますRV64っていうのはリスク5で64テストで64ビットのインストラクションセットを持っているということです64ビットCPUのリスク5ですSV39っていうのはMMUがありますという形の技術になりますなのでMMUありの64ビットのリスク5で動かしているという形ですSMの隣にキーストーンって答えますがSM自体はセキュアモニターの略ですがリファレンス実装が公開されておりますこちらに対してTUが動くように具体的にキーストーン何タイムとリナックス側を端私をきちっとセキュリター持ってできるようにPMPを使って動くようにするためにキーストーンプロジェクトでSMを拡張して実装しておりますのでキーストーン拡張のSMという形です今度はキーストーン何タイムですがキーストーン何タイムっていう形に設計が分かれているのはこの上で例えば今回はうちはGPAPIでティープのための実装を行いましたがここを入れ替えてセキュリティで有名なセルフォーオーエスをTOSを乗せたり実現されておりますあともう一つはソフトウェアのコンポーネントの設計ですがTプレジェントTAとハローTAとこちらコンテキストスイッチというかPMPで分かれて実行されますですので具体的にはGPAPIのソースコードがあったとしてもこの協会を超えてGPAPIが伝般することはない形になっています実際にこれ大事なことで実用で行うまた実サービスで行う場合はハローTAは決済会社ですとかストリーミング会社は自分たちのTAのアプリのコードは公開せずクローズドソースでビジネスをする形になりますのできちっとそれが実現できる形になっていますはいここからはITFでどのように議論を進めているかという話を行いますまずITFは3回ミーティングが開かれますこの時にかわわせて議論をいたしますそれ以外はほぼメイリングリストを使ってコミュニケーションして企画または技術的議論を進めてドラフトも作成までいくと企画作成までいくというのがもともとのITFの文化ですでここ最近はITFのミーティングに合わせてハッカソンが開催されていますですので我々の実装マイノページの実装を持ち込んで他の例えばとアームから参加されたハーネスさんとかマイクロソフトからデイブテイラーさんが持ち込んだタムサーバーと総合互換検証を行ってその場の議論でフィードバックしたりまたはドラフトに反映させたりということを行っていますまたメイリングリスト以外に最近ギットハブという非常に便利なツールがございますのでここでギットハブも使ってコミュニケーションしておりますではまずメイリングリストへの議論のご紹介いたします下に針をつけたりあるのは私がティープでCDDLというのは何のことかってのあとのスライドに出てきますけどティープのメッセージのフォーマットこんなのはどうでしょうっていう形で提案した時のメールになりますこれが取り入れたことで応産の人になれたきっかけになりました何か提案した時技術的にコンコンと説明して技術的にOKだったら取り入れられるっていうような形を後回の場で行いますなのでみんなで見ているところでメイリングリストでいろんな人の意見をどんどん取り入れていくという形ですでも取り入れるって言われても技術的にコンコンと説明して相手が納得しないといけませんのでそこはオープンソースのメイリングリストの領域と非常によく似てますですので私はオープンソースでのメイリングリストのオーサフォーをこちらの相手のメイリングリストで使って得したという形になりましたはいそれではこちらギッドハブでの例をお見せいたしますティープのドラフトは今年になってほぼすべてギッドハブでのドキュメントの更新に移行いたしましたですので他のオープンソースのプロジェクトのように一周で意見や質問を行ってプロリクエストで変更の提案をしてでレビューしてオッケーであったら取り込まれるという形でどんどんドラフトが更新されてっておりますで左の例はC4のテキストとバイナリーを変換するときに私が手でハンドアセンブル間違いところを更新修正するためのプロリクエストですハンドアセンブルしてディスアセンブルしていた経験がC4のドキュメントを見ながら手で変換してっていうのを今でも繰り返して今役に立ったという状況になっておりますで右の方はC4のメッセージもともとは企画にいくつかメッセージクエリーリクエストレスポンスアプリケーションインストールデリートティープサクセスエラーっていうような形でいくつかメッセージあるんですが具体的な技術例がなかったものですから私がプロリクエストを出したという例になっております11月から私がこちらティーププロトコルのギットハブのメンテナーをしておりますこのメッセージの詳細を次のスライドでお見せしていきますこちらがC4の表記になります今右下が実際コンピューターが処理する16新法技術ですox 838から始まればあれであるox 8から始まるとマップである その他いくつか決まり事がありますがC4のドキュメント読んでハンドアセンブルを何度も繰り返していると8さんから始まると連取に3つあるのかなa 2だと連取2つあるのかなってだんだんだんだん16新読んだだけでちょっと頭の中で変換できるようになりますがこれではプログラミングしにくいですし 企画書に書けないのでこれはC4の16新のバイナリーの技術ですがこれをもともとC4のダイアグのステクノーテーションって技術方式があってこれはどちらかというとジェーソンから来た人またはジェーソンと相当のものの技術の仕方にそっくりにあいように設計してありますこちらだけでも実は意味を組んでC4のダイアグのステクノーテーションを書くというのがあまり便利ではありませんのでコンサイスデータデフィニッショナンゴイズなくしてCDDLという形が上の真ん中に貼り付けてありますですのでドラフトではCDDLの例を提してそれをC4ダイアグのステクを見ながらバイナリーに変換して実際に実装して総合5完成を取っていくという形になりますバイナリーの変換した結果を見てもうちょっと企画でこうした方がいいんじゃないかまたはこういう技術が不便だとか抜けてたとか余計にあったとかいうのがあると企画に提案をどんどんメイリングリストまたはギットハブでしていって提案して取り入れて更新してもっとどんどんみんなで良くしていくというような形で進めておりますスライドの方も最後になってまいりましたでこちらは11月にITF109が解散されたときましたのでその時のハッカソンに行ってそれのフィードバックによってTプロトコードがどのように更新されて良くなっていったかというのをいくつかデッキをいたしましたですので123456今6個あげてありますが一番最初はCボアのダイアゴニックノーテーションとバイナリーの例をプティープのプロトコードラフトに追加できたこれがあるなしでは実装の大変さがものすごく違っていますテキストで書いてあるだけで実装してって実際に他のサーバーと通信してみるとあれおかしいなって言った時によりところはやっぱりバイナリーがまでお季節がないと非常に苦労いたしますここで追加できて嬉しかったですあと今までこのスライドすべてクリティカルアプテケーションはトラステットアプテケーションだと説明してきましたがいきなり11月から名前が変わってしまいましたトラステットアプテケーションがなんとトラステットコンポーネットになってしまいましたなので今までの話はトラステットアプテケーションを今後全部トラステットコンポーネットTAでなくてTCと喋らないといけないという形ですでもそもそもなんで名前を変えたかということなんですが実際タムサーバーとデバイスのやり取りではアプテケーションだけではなくてデータだけのやり取りっていうのもありますそれも想定して動くようにしてありますスートマニフェストで中身がアプテケーションでなくてもバイナリーでなくてもデータのバイナリーであってもオッケーなように最初から想定しておりましたただ名前がトラステットアプテケーションでは間に合わしいということでデータも含めてわかりやすいようにトラステットコンポーネットにしようという話があって2020年の10月になって今さら言いますかっていう気はちょっとだけあるんですがまあこれで行くことになりました技術的にこっちの方がマットなので反応はしにくいですもう一つはTAのIDっていうのがどうしても必要です今名前がTCのIDになってしまったんですがデバイスで必要なTCもうちょっと大変なのでこのスライドではTAでTCと言わずにTAで通しますがTAのバイナリーの識別詞がないとデバイスとTAでどのバイナリーを取得していないといけないかっていうのがわかりませんそれをマニフェストの中で識別するためのIDが必要なんですがそれはスートコンポーネントアイデンティファーをTAのID、ここではコンポーネントIDに使うというふうに決まりました今までTAのファイル名にしようかだとか余裕IDを使えばいいんじゃないかだとかあとはスートコンポーネントアイデンティファーに相当するもののスートマニフェストの技能があったんですがそこはスートダイジェストを使うということになりましてスートコンポーネントアイデンティファーを使うここで一つ今まで企画のドラフトとしては少し曖昧だったところが非常にカッチリなりましたでもう一つはティープのメッセージなんですがサーバーとデバイスのやりとりの往復をトークンでマッチングさせて識別するというのがティープのメッセージの基本設計でしたところがいくつかのメッセージ具体的にはサーバーから一番最初タムサーバーから一番最初デバイスやりとするクエリーリクエストとクエリースポンスはトークンがなくても動くとトークンが入って帰ってトークンでTAをと識別して実装してしまう人たちがいるとセキュリティ的によくない影響があるのでトークンがティープメッセージに今まではマンデートリーでエントリーとして入ってたんですがこれオプションになりましたこれも日本からの具体的にはセコモのイソベさんからの提案でしたあとデバイスとタムサーバーでデータのバイナリーまたはTCのバイナリーTAのバイナリーを消さないといけないという状況もあります例えば以前お話したようにサービスが終了したとかもうまた新しいバイナリーが出てるとかもうこのデータはもう必要ありませんとか言った時に消せないといけませんそれのやりとりをどうやってタムサーバーにデバイス側から通知するかっていうのが今まできちんとした方法がなかったのでここでアンニーレットTCリストに技術することでデバイスからサーバータムサーバーに通知できるという形になりましたあとこれは一緒に実装してるデビタムさんからのアイデアでコントリビューションなんですがスートマニフェストをティーププロトコの中で埋め込んで使ってるんですがここで埋め込み方を一つのスートマニフェストを一つのバイナリーにしてシーボーのバイナリーにして埋め込んだ方がいろいろ都合がいいんではないかという話をして itf109のサイドミーティングでそれでいいじゃないですかという話になって採用されましたですのでまあこの中で3つぐらいは日本からの提案がきちっと生かされているという形で進んでおりますはいではまとめです一番最初はティープとは何度やという話をお話しいたしましたでなんで t っていうのはクリティカルアプリケーションとかまとは個人データのようなセンセティブなデータで必要であるか大事であるかというお話をいたしました で最近の cpu のアーキテクシャーでどういうふうに t が動いているかまあ実際にリスクファイブの例でお話しいたしました キーストーンはリスクファイブでどういう風で動いているかとお話しいたしましたITFでティープをどうして標準化活動して技術開発しているかということをお話しいたしましたまあここに書いてあるように具体的には違うデバイス違うサーバー違うベンダーで トラステッドアプリを統一した方法でインストールデリートできるようにする方法が必要でそれでティープを標準化しているというのは答えになりますあと ティープティープのITFドラフトが3つあったでワーキングループ3つあったりするのでそれらの関係をお話しいたしましたはいでその後我々の今の緊急開発のリスクファイブでティープをどういう風にしているかというお話をいたしましたでその時にグローバルプワット方面一部案は何で必要でどういう風に動くようにしたかというご紹介をいたしましたあとはITFでの議論の仕方あとはCボールドのバイナリーの具体的な例をお見せいたしましたはい こちらが最後本日の発表をもっと深掘りしたい方はこちらのリンクをぜひご覧になってもしここ間違ってますとかもっといい方法がありますなんていうのがありましたぜひメイディングリストまたギットハブにぜひ参加していただきたい それを願って今日は話を終わりにいたしますありがとうございました