テルアビブ大学の研究者曰く、ARM の TrustZone のセキュリティ実装にはオープンな標準が必要 29
ストーリー by headless
標準 部門より
標準 部門より
Samsung 製 Android スマートフォンで TrustZone OS (TZOS) の暗号機能に見つかった 2 件の脆弱性について、発見したイスラエル・テルアビブ大学のチームが論文 (PDF) と POC を公開している
(The Register の記事、
Android Police の記事、
SlashGear の記事)。
ARM ベースの Android スマートフォンでは Android OS から独立して Trusted Execution Environment (TEE) 上で実行する TZOS にセキュリティ上重要な暗号機能が実装されるが、その暗号機能実装はベンダーに任されており、非公開でプロプライエタリな設計になっているという。研究チームは Samsung のフラッグシップデバイス Galaxy S シリーズを調査し、ハードウェアベースのキーストア (Keymaster TA) の暗号設計と実装を明らかにした。
2 件の脆弱性は Galaxy S9 の AES-GCM で見つかった IV 再利用の脆弱性 (CVE-2021-25444) と、より新しい Galaxy S10 / S20 / S21 でも IV 再利用攻撃を可能にするキーブロブダウングレード攻撃の脆弱性 (CVE-2021-25490)。前者は昨年 5 月に Samsung へ報告し、Galaxy S9 のほか Galaxy J3 Top / J7 Top / J7 Duo / TabS4 / Tab-A-S-Lite / A6 Plus / A9S を対象としたパッチが 8 月に公開されている。後者は 7 月に報告し、Android P 以降をプリインストールしたデバイスを対象としたパッチが 10 月に公開された。こちらのパッチではレガシーなキーブロブ実装が完全に削除されたとのこと。いずれの脆弱性も Galaxy S9 よりも古い S8 には存在しない。
今回の脆弱性は 1 億台程度の Samsung 製デバイスに適用されるのみだが、ベンダー各社が TZOS や TA (Trusted Application) のセキュリティや暗号の設計・実装を秘密にすることが危険な落とし穴になっている。各社はプロプライエタリシステムのリバースエンジニアリングの難しさに依存するのではなく、外部の研究者によって十分な検査ができるようにすべきだと研究チームは結論付けている。
ARM ベースの Android スマートフォンでは Android OS から独立して Trusted Execution Environment (TEE) 上で実行する TZOS にセキュリティ上重要な暗号機能が実装されるが、その暗号機能実装はベンダーに任されており、非公開でプロプライエタリな設計になっているという。研究チームは Samsung のフラッグシップデバイス Galaxy S シリーズを調査し、ハードウェアベースのキーストア (Keymaster TA) の暗号設計と実装を明らかにした。
2 件の脆弱性は Galaxy S9 の AES-GCM で見つかった IV 再利用の脆弱性 (CVE-2021-25444) と、より新しい Galaxy S10 / S20 / S21 でも IV 再利用攻撃を可能にするキーブロブダウングレード攻撃の脆弱性 (CVE-2021-25490)。前者は昨年 5 月に Samsung へ報告し、Galaxy S9 のほか Galaxy J3 Top / J7 Top / J7 Duo / TabS4 / Tab-A-S-Lite / A6 Plus / A9S を対象としたパッチが 8 月に公開されている。後者は 7 月に報告し、Android P 以降をプリインストールしたデバイスを対象としたパッチが 10 月に公開された。こちらのパッチではレガシーなキーブロブ実装が完全に削除されたとのこと。いずれの脆弱性も Galaxy S9 よりも古い S8 には存在しない。
今回の脆弱性は 1 億台程度の Samsung 製デバイスに適用されるのみだが、ベンダー各社が TZOS や TA (Trusted Application) のセキュリティや暗号の設計・実装を秘密にすることが危険な落とし穴になっている。各社はプロプライエタリシステムのリバースエンジニアリングの難しさに依存するのではなく、外部の研究者によって十分な検査ができるようにすべきだと研究チームは結論付けている。
模範的実装 (スコア:0)
appleとかGoogleとかの実装がどんなもんか知りたい
Re: (スコア:0)
AppleはSecure Enclave、
https://support.apple.com/ja-jp/guide/security/sec59b0b31ff/web [apple.com]
GoogleはTitan Mですね（Pixel 6は違うかも）
https://www.blog.google/products/pixel/titan-m-makes-pixel-3-our-most-... [www.blog.google]
どちらもメインのCPUから独立したプロセッサであり、特にGoogleの場合はQualcomm SoCのTrustzoneを使う手もあったのにわざわざ自前のチップを設計しています。両者ともにセキュリティのためにはプ
Re: (スコア:0)
pixel6はM2ですね。
RISC-Vらしいです。
Re: (スコア:0)
pixel6はM2ですね。
RISC-Vらしいです。
リンゴさんも乗り換えるかもね、中国もRISC-Vを作ってきてるし
(*´ω｀*)
Re: (スコア:0)
HSM(暗号処理を担う外部プロセッサ)と、TrustZone(メモリ空間のアクセス権を分けるARM CPUの標準技術)って、
二者択一じゃなくて両立するものじゃないの？
iPhoneやPixelが具体的にどう実装してるかまでは詳しくないんで間違ってたら指摘がほしいんだけど、
TrustZoneでのみ使えるようなメモリ空間とレジスタのアクセス権を設定し、
そこの中の実装がTrustZoneの外(==AndroidOS)からは見えないようにして、
そこにHSMと通信する実装を入れ、
改ざんできないようにここの展開とアクセス権設定をするブートローダを署名＆暗号化してストレージに格納し、
署名の連鎖はLSI中のiROMレベルから行われ
Re: (スコア:0)
実際の処理をコプロセッサに出すのは不具合発生時の修整と検証の手間を下げたいからかななんて思う。
ハードウェア上の不具合があってもチップ間のインターフェイス部分に問題がある場合を除きコプロセッサだけ変えてコプロセッサだけ検証すればいいはずだから。
一方で多様性もないといけない (スコア:0)
オープンにするのは充分な監査の目を入れるためだろう。
だが一つの標準に多数のベンダーが群がるのもまた不健全だ。
攻撃者は一つの標準を狙えば良くて攻撃コストが下がるし、何かあったときの影響範囲が大きすぎる。
ベンダーがそれぞれ実装し公開するのがベター。
Re:一方で多様性もないといけない (スコア:1, すばらしい洞察)
その理屈はおかしいと思う。
セキュリティは複雑さによって守られてるわけじゃなくて、単純さと堅牢さは両立する。バグがあれば何もかも台無しになるわけだから。イタチごっこにしたらどこかの局面でメーカーは絶対に負けるからそれは避けないといけない。
Re:一方で多様性もないといけない (スコア:1)
一つのソフトウェアに依存すると、一網打尽でやられるって話だよ。
heartbleed, shellshock, 最近だと log4shell。もう忘れたかね。
Re: (スコア:0)
破られること自体は避けられない。そのほうが結果的にに傷が浅いってことだよ。
docomoのS9は (スコア:0)
サポート終了宣言後でパッチ来てないんだよな…
Re: (スコア:0)
auのS9も昨年6月版のパッチを最後に振ってきてないんですよね
auはサポート終了宣言しないのかな？
Re: (スコア:0)
サポート終了宣言後でパッチ来てないんだよな…
そもそも日本キャリアモデル使っている時点で物理的に買い替えていくことがアップデートを維持する唯一の方法ではないかと
# 海外モデルを買って技適マンを華麗にスルーというスタイルもなくはない
IV再利用 (スコア:0)
何で無くならないんだろう。どういう落とし穴があるのか。
Re: (スコア:0)
TLSでもBEAST攻撃があるまではCBCモードの初期ベクトル再利用の問題は軽視されてたしね。
さらにGCMでの初期化ベクトル再利用が、CBCモードのそれよりリスクが大きいことを知らんのだろう。
＃次はインクリメントが単純なケースを攻められそうな気も…。
とは言っても、使う側は、結局は計算量次第と早々に理解を諦めてしまって、
裏で何やっているか知られないことに重きを置き、本当に攻撃されるかどうか分からないものは、
問題になってから対策すればいいや、的な意識もありそう。
暗号関係の研究者も研究者気質で、使うときのポイントを明快に説明出来ない人が多い。
サルでも分かるように説明することを毛嫌うというか…。
そんで、結局はどっかから買ってきたIPを使うんだろうけど、その時点で脆弱だったりもするよ
Re: (スコア:0)
そんな複雑な話ではなく、プロセッサを作る側も買う側もそこまで完全なセキュリティを求めてないだけなんじゃないの。
建前では何と言おうともすべてはコストとの兼ね合いなので。
問題が残ってるのも、検証のコストをかけてないからとも言える。
研究者がどれだけの潜在的な危険があると言ったって、プロセッサを作る側や買う側から見たコストとして響かなきゃ対策する意味がない。
これはプロセッサを作る側が理解できてないという意味ではなく、理解したうえでそこまでのコストをかけないと判断したという意味。
今回のように後から対策するコストの方が、設計時の検証コストを
Re: (スコア:0)
そういう一般論は別のツリーでやってもらって。
完全なセキュリティを求めないと、なぜIVが再利用されるの？
Re: (スコア:0)
買ってきたIPをそのまま使うのが、コスト意識からだという指摘では?
分かってないわけではなく、その程度の重要性しか見出してない。
Re: (スコア:0)
ひり出してきたIVをそのまま使うのが、コスト意識からだ、ってやつね
インクリメントでいいからやれっていうのは、実務知識感ある
Re: (スコア:0)
記事と上の #4206992 と #4207037 で答えになっていると思うけど。
>完全なセキュリティを求めないと、なぜIVが再利用されるの？
その質問を繰り返されても、どういう答えを欲しているのか分かりかねます。質問を練り直した方がいいかと思います。
Re: (スコア:0)
IV再利用がセキュリティーホールになるなら、IV再利用を無くせばいいじゃん！！ 何で無くならないんだろう。ってことですか？笑
Strong ARM辺り由来の (スコア:0)
脆弱性だらけじゃね？
フリー実装のTrustZoneつかったOSがあれば (スコア:0)
FreeBSDとLinuxで、TrustZone有効化したディストリビューションを作るしか無いな
もちろん、追加コード・追加プログラムは全部ソースコードをオープンなライセンスで公開
暗号技術入門[第3版]に (スコア:0)
“仕組みを秘密になっている暗号化は、必ずしも安全とは言えない”的な事が書いてあった。こういうのが実際の例かしら
Re: (スコア:0)
仕組みを→仕組みが
Re: (スコア:0)
それじゃなんでも公開すれば良いのか？っていうと、そうでも無い。
脆弱性が見つかったら敏速にアップデート出来る環境が無いと、その脆弱性を利用したハッキング被害の方が大きくなるだけ。
androidってGoogleの他に製造メーカーやキャリアも絡むので、最新状態が維持できているとは言えないよ。
ニーズがあるなら (スコア:0)
セキュアソフトウェアの専門家を揃えてセキュリティ関連のソフトウェアライブラリを開発して販売したり、
堅牢さを検証して保証するような商売をする会社が出てきそうなもんだが、ないのかね。
Re: (スコア:0)
> 会社が出てきそうなもんだが、ないのかね。
いまさら何を言ってるんですかね？その手の会社はスラドでも度々登場してますよ。
Re: (スコア:0)
TrustZoneでの堅牢なセキュリティ実装を売っているところがあるの？