• ホームページ
  • 問い合わせ

TPMは全てのセキュリティの基点 TPMのないところにセキュリティなし

ホワイトペーパーのPDF版はこちらからダウンロードしていただけます。

 

TPM(Trusted Platform Modules)は、全てのPC端末に搭載されているか、またCPU自体に組み込まれている小型の半導体デバイスです。

それは暗号キーの安全な保管場所です―多くの点で決済カード上のチップに似ています。TPMは長年にわたりPCおよびラップトップ内に搭載されて出荷されてきました。しかしTPMは銀行ATMのネットワークには適切に配置されていません。多くの場合、新しいセキュリティ体系の導入に消極的であることが原因です。ATMネットワークが、多くの産業界に比べ暗号によって安全を確保する必要がより大きいことを考えればこれは驚くべきことです。
事実上、TPMは単なる鍵の保管場所以上の存在です。それはPCを利用するネットワーク上のあらゆるセキュリティ保護において信頼できる技術基盤なのです。それはATMネットワークに対しても同等になります。
本白書は、銀行がATMのセキュリティ体系を設計する際に心掛ける事、また銀行業界が暗号技術を使ってハードウェア、ソフトウェアおよびネットワークをロックダウンするには、TPMをどのように活用すべきかを考察しています。

はじめに

使い勝手を損なうことなくATMの安全性を可能な限り高める必要があることは、周知の事実です。しかしどの様にすればそれを実現できるかについては、見解が異なります。もちろん一部の混乱は、TPMとは異なるセキュリティ製品を販売するベンダーが、顧客の関心を引くため行っている競業から生じています。しかし、顧客を混乱させ、最終的にセキュリティに対する攻撃に対して脆弱な、不十分な実装につながる不正確な情報が多く存在することも事実です。

本白書は、個々のコンピュータシステムがどのように保護されるべきかの原点から始め、次に、当然ながら最高レベルの保護を必要とするATMネットワーク独自のケースに注目して、セキュリティシステムの重要な基盤条件をまとめます。ATMネットワークは、多額の現金に対する責任を持つだけでなく、世界中で多くの現金を移動できる銀行のホストコンピュータシステムへの入り口にもなり得ます。ATMが危険にさらされると、その金庫内に保管した現金より多くの費用を銀行が負担しなければならない可能性があります。

まず、セキュリティに関してよくある誤解について考えてみましょう。セキュリティシステムの最大の誤解は、おそらく階層的セキュリティ構造の概念への誤解です。

複数の協調的なロックが必要である複雑なシステムの場合、単一の特効薬はないというのが現実です。しかし、その概念は、セキュリティが不明瞭で複雑であればあるほど、システムは安全であると意味するというように誤解されることがあります。これは事実無根の解釈にすぎません。単純で、オープンに議論でき、十分に理解しうる、セキュリティ体系の中心を形成すべき基本的な暗号技術があります。この技術は、定量化できるセキュリティを提供するだけでなく、使い勝手が良く、実行にユーザーの曲解を必要としません。

簡単に理解できる例を示してみましょう。以前は誰もが、ログインのためにユーザー名とパスワードを入力しなければならないPCシステムを使っていました。パスワードのセキュリティシステムがハッカーの標的になったため、会社などの組織はより複雑なパスワードルールを構築するようになりました。それは、定期的なパスワード変更が必要であるほか、過去数回のパスワードを使えない、複雑すぎてパスワードの文字列を記憶するのが困難であるなどの問題があり、正規のユーザーには極めて使い勝手が悪いものです。Microsoftは「Windows Hello」により、こうした問題を全て解決しました。

Windows Helloは、TPMで保護した暗号化安全ハードウェアデバイス認証と生体顔認証を結び付けた技術です。これは事実上、ATM業界がよく知っているチップアンドピンに非常によく似た安全性に対する概念です。Windows Helloでは、チップは決済カード上のチップと同種の暗号処理を行い、生体情報はピンの働きをします。このシステムは、これまでに使われたどのユーザー名とパスワードのシステムよりも安全であるだけでなく、極めて使い勝手が良くなっています。Surfaceタブレットの画面を見るだけで瞬時にログインでき、しかもその時間はパスワードの最初の1字を入力する時間より短いのです。システムをさらに安全で、使いやすくすることはできるでしょうか。もちろんです。「苦労なくして利益はない」という考えを忘れる必要があります。本当の安全はユーザーの苦痛を必要としません。

読者は、前節でTPMの概念が紹介されたことをご理解頂けたと思います。本白書は、TPMをコンピュータの「完全性の基点」とする考えを基にに構成されています。TPMは、Intel、Microsoft、HPおよびIBMなどの大手企業を含む100社以上のTrusted Computing Group(TCG)が設計したセキュリティ体系で構成される保護用半導体チップです。この団体の作業は1999年にすでにスタートしています。その目的は、コンピュータデバイスのためのセキュアコアを創出し、全てのコンピュータのセキュリティをこのセキュアコアの上に築けるようにすることです。朗報は、全ての新しいPCにTPMが完全標準装備されたこと、しかもそれが何年も続いていることです。悲報としては、多くの組織が使用しているPC内にTPMが整備されていることすら知られておらず、その強固な機能を活用してていないことです。本白書は、そうした状況、特にATM業界を変化させる目的をもって書かれました。結局、あらゆる業界の中で安全なコンピュータシステムを最も必要としているのは私たちの業界なのです。

TPM – 「完全性の基点」

「完全性の基点」は何を意味し、TPMがコンピュータのセキュリティにとって極めて重要なのはなぜでしょう。それを理解するには、全てのコンピュータセキュリティは暗号化の適切な利用に左右されることを認識することが重要です。暗号化とは、保護すべきデータに処理を施し別のデータにし、再び判読可能な状態にする技術です。

データまたは情報が平文の場合、意図する目的に使えます。データが暗号化された場合、復号化されない限り使用できません。暗号化および復号化するのに極めて重要なことは、暗号化にも復号化にも安全鍵が必要だということです。鍵がなければ、暗号化したデータは使い物になりません。実際に、「鍵」という言葉はその意味で、金庫のキー(鍵)と変わりはありません。金庫の鍵を失えば、中の金地金を手にすることはできません。コンピュータの場合、金は暗号化処理で保護されたデータです。

そこで、理解するために重要なことは、鍵自体はメッセージを復号化できるよう暗号化されていないものでなければなりません。それは鍵を安全な方法で保管する必要があることを意味します。そうです。その鍵を、別の鍵を使って暗号化できるのです。これによって最初の鍵は安全に保管されます。しかし第二の鍵をどこに保管すべきか、という問題が生まれます。実際に鍵の連鎖を持つことは可能です(そうした鍵は多くのユーザーが持っています)。ただし、最初の鍵は暗号化されていないもので、どこかに安全に保管する必要があります。コンピュータ内のどこに暗号化されていない親鍵を保管できるでしょうか。ハードディスク(SSD)上には「できない」が答えです。暗号化されていない鍵をドライブ上に安全に保管することは不可能です。ドライブに物理的にアクセスできるハッカーは、必ず暗号化されていない鍵を見つけます。攻撃者が物理的にアクセスできるなら、ソフトウェアだけでは保護することはできません。

TPMになら保管できます。TCGは機密情報を保護するハードウェア上の金庫室としてTPMを設計し、それをマザーボードに埋め込みました。CPU自体の内部にTPMを入れる設計も可能です。まさに鍵を安全に保管するという目的のもとで設計されています。単に鍵を保管すること以外に多くの機能を持っています。そのことを次の項で見てみましょう。今のところ、コンピュータシステムは鍵の連鎖を持っているかもしれないと考えてください。しかし連鎖されている暗号化鍵の最初の鍵は暗号化されていないはずであり、信頼できる目的にのみ使えるように極めて安全に保管されなければなりません。TPMはそうした鍵の保管場所です。

CRTM –信頼のおける完全性の計測

私は、TPMは単なる賞賛すべき鍵の保管場ではないと請け合いました。作業の最初の日に、安全鍵の保管場所が直面する最初の問題を考えてみましょう。誰かがTPMに、「暗号化されていない鍵を表示してくれますか」と問い合わせたとします。その鍵を要求した人物が何者かをどうやって判断できますか。鍵を安全に保管できるのは良いですが、その鍵を誰に渡そうとしているのでしょうか。鍵の使用を求める正規のコードが使われているのでしょうか。それともマルウェアでしょうか。ハッカーがPC上でマルウェアを使ってソフトウェアを改変したのでしょうか。そしてとても丁寧に、「TPMさん、鍵を使わせてください」と入力します。問題はおわかりですね。単に安全な鍵の保管場所であるというだけでは不十分すぎるのです。こうした鍵の使用を求めるソフトウェアを認証する必要があります。次にセカンドパーティによるTPMの仕掛け、すなわち信頼のおける完全性の計測(CRTM)の説明に移りましょう。

CRTMは電源を入れた瞬間に信頼チェーンと共に動き始めます。ハードウェアとTPMは協力して初期ブートからBIOS/UEFIまで、オペレーティングシステム(OS)が始動するまでの全工程でPCの起動シーケンスを「測定」します。「測定」によって、始動プロセスの最中にPC上のソフトウェアが改変または改ざんされたかどうかがわかります。このプロセスは、現在ではPCを起動するためにUEFIを使用している新しいPCコアの標準機能であるセキュアブートとして最もよく知られています。

セキュアブートを支援するために、PCR(プラットフォーム構成レジスタ)と呼ばれるコンセプトがTPM設計に取り入れられています。PCRの値は「PCRの拡張」と呼ばれるプロセスでTPMによって、ブロックチェーンの生成と幾分似た方法で計算されます。その結果PCRは、PCの起動シーケンスの固有の指紋(すなわちhashesのセット)を持ちます。PCRが過去から改変されていなければ、PCの起動ソフトウェアは改変されていません。これは暗号によって保証されます。PCRの値に影響を与えずに、測定された起動ソフトウェアの1バイトにもマルウェアが改変を加えることは不可能です。

 


tpm diagram 1セキュアブートを支援する

これは暗号化において極めて重要なコンセプトです。「安全なハッシュ機能」と呼ばれる機能は暗号化に似た機能で、データブロックを元データの拇印として機能する固定長の文字列に変換します。データが変更されると、拇印も変化します。したがって、これはサイズの大きなソフトウェアにほんのわずかな改変を加えただけでも、検出する確実な方法です。TPMはHMACと呼ばれる様々なハッシュ法を使用しています。HMACは「鍵付きハッシュ」のことで、正しい安全鍵を所持する者だけがHMACハッシュを生成または検証できることを意味します。これはある種の「暗号化されたハッシュ」です。

この項で詳細を掘り下げて述べるのには理由があります。これは、TPM技術がATM内のコアソフトウェアが完全に安全であることを保証する方法なのです。TPMに保護されたATMの起動シーケンス内のソフトウェアの1ビットも、最新の暗号技術自体を破壊することなく改変する方法はありません。これは、ATMの他の全ての機能を保護するために本白書で述べるコンセプトでもあります。

安全なソフトウェアコアを手に入れました– では、アプリケーションソフトウェアはどうでしょう?

Windows 10 ATM上では、現在のところ引き継ぐMicrosoftの重要な技術が2つあります。BitlockerとDevice Guard(Windows Defender Application Control ‒ WDAC)です。BitlockerはMicrosoftのドライブ暗号技術で、ハードディスク(SSD)上の全情報を暗号化できます。また最も重要なのは、「TPM内に」ドライブ暗号化鍵を保存することです。実際には、TPMに単に鍵を保存するより少々複雑です。もう少しはっきりさせてみましょう。

鍵を安全に保管するだけでは不十分で、鍵を提供する前に「誰が」それを要求しているのかを確定することが不可欠であることを頭に入れておいてください。TPMには鍵を「シーリング」というもう一つの新しい仕組みがあります。ATMのドライブが最初に安全な環境で暗号化され、Windowsによって新しい鍵が生成されると、この鍵は別にある「親鍵(KEK)」を使って暗号化されます。KEK自体は「シーリング」と呼ばれる処理で、PCRの値とTPMの秘密鍵を使用してさらに暗号化されます。ATMを起動しても、PCRで測定されたコアソフトウェアの拇印が全て認証されない限りKEKキーを使うことはできません。このことは、上述した通りBIOSおよびWindowsコードが改ざんされていないことを意味します。WindowsはKEKを使用して、ドライブ暗号化鍵を復号化し、これを使ってドライブ全体を復号化します。KEKが読み出されると、Windowsは後ろにあるKEKのドアを閉じます。このプロセスはPCR 11を「拡張する」ことによって実行されます。すなわち、KEKが取得されると、PCR 11が変更され、その後誰もKEKを読み出すことができなくなります。KEKは次の起動シーケンスまで安全に保管され、コアソフトウェアが一切改ざんされていないことをPCRが確認できるまで使用できなくなります。そしてBitlockerがKEKを使用してドライブを復号化すると、直ちにドアはロックされます。

ご覧のとおり、私たちは、起動プロセスを完了し、Windowsを読み込むまで、各ステップをチェックしながらPCRを使用して何ら改ざんが行われていないことを確認して、コアソフトを少しずつ作り上げてきました。次に、ATMアプリケーションソフトウェアを起動し、実行可能な全てのファイルが改ざんされていないことを利用する前に検証する必要があります。すなわち、全てのソフトウェアコンポーネントの拇印を使用前にチェックするという、同様のコンセプトを拡大します。起動チェーンの最終段階は、Windows WDAC(または同じ機能を持つサードパーティソフトウェア)により実行されます。これはホワイトリスティングと呼ばれることがあり、結果的に実行が許可される前にチェックされる全ての実行可能なファイルのハッシュ(すなわち計算された拇印)になります。

ATMのホワイトリスト化

Windows WDAC(または他のホワイトリスティングソフトウェア)を使ってATMソフトウェアをホワイトリスト化する最良の方法は、「certificate rule(証明書の規則)」と呼ばれる規則を使うことです。これには、ATMに配置したソフトウェアが、ソフトウェア開発者によって事前に署名されている必要があります。したがって、例えばWindows 10の実行可能なファイルは、Microsoftが同社の秘密鍵を使って署名しています。このことは、Windowsの実行可能なファイルが移動中に改変または改ざんされていないこと、およびMicrosoftが同社のコード署名公開鍵を使ってこれらを簡単に検証したときと、現在も同じ状態にあることを誰もが検証できること意味します。これをWDACに確認させるために必要なことは、Microsoftが署名した実行可能なファイルは安全に使用できることを示す「証明書の規則」を作成することだけです。

同様にKALのソフトウェアは常にKALのコード署名秘密鍵で署名されています。当社のお客様は、各ATMにKALのコード署名証明をインストールすることで、KALソフトウェアが改ざんされていないことを検証できます。

しかし、事前にそのように署名されていないソフトウェアはどうでしょう。銀行が利用できる3つのオプションがあります。

  1. ベンダーにコードを署名させる。
  2. ベンダー契約を打ち切る(2020年にコードを署名しないベンダーは本当に存在するか。「どうやら存在するようだ。」)。
  3. 「ハッシュ規則」を利用する。

ハッシュ規則は、お客様がWDAC用にホワイトリストに追加する規則で、銀行はそれによって、実行可能ファイルに署名しないベンダーからの各ファイルのハッシュを計算します。言い換えれば、お客様がベンダーの代わりにコード署名をするのです。ベンダーから銀行までの輸送中にどんな改ざんがあっても検出できないため、これは明らかに、ベンダー側での署名に比べて好ましいことではありません(安全に伝送する方法は他にありますが)。

このような導入方法で二番目の不都合な点は、銀行が全ての実行可能ファイルに「ハッシュ規則」を作成する必要があることです。これはATMにベンダーの公開証明書をただインストールするだけの方法に比べ、洗練度が著しく劣ります。ベンダーの証明書をインストールすると、将来のベンダーによるアップデートを含め、ベンダーの全ての実行可能ファイルが自動更新の対象になります。

まだそこに達していない?

私たちがここまで達成し、ATMが稼働すれば、全てのソフトウェアが暗号によって検証済みです。何らかの方法で改ざんまたは改変された実行可能ファイルは、実行を許されません。最新のATM内で実行可能なソフトウェアに含まれる数ギガバイトの情報の1ビットも、検出や阻止を免れてハッキングされることはありません。

しかし私たちはまだそこに達していません。このような方法で保護されたATMは、ソフトウェアスタックの不正な改変に関するかぎり、攻撃を受けても問題ありません。ただし、ここで話は終わりません。ATMにマルウェアを注入することは、ATM攻撃の唯一の方法ではありません。私たちは、TPMが他のタイプの攻撃にどのように対処できるかをこの後考察します。

TPMに何ができるかを理解

TPMはただATMの起動プロセスを保護するだけではありません。それは、他の全てのものも保護されるようにする完全性の基点です。TCGのメンバーであるWill Arthur、David ChallenerおよびKenneth Goldmanが共同執筆した素晴らしい書籍をのぞいてみましょう。その本、『A practical guide to TPM 2.0(TPM 2.0の実践ガイド)』は、傑出した内容で、アイディアの宝庫であり、私に本白書執筆の動機付けをしてくれました。同書はこちらからダウンロードできます。

同書を本白書で素早く要約する最良の方法は、同書にリストアップされた53のユースケースに焦点を合わせることです。著者の許可を得ているので、その事例を以下に挙げます。

1. 起動パラメータの保存

2. VPNキーアクセス

3. プライマリキーの最適化

4. アイデンティティキーのプロビジョニング

5. リソースマネジャーにTPMキーの安全な管理を許可

6. 同一の機会にキーを交換するアタッカー

7. UEFI

8. 認証間のリブートの検出

9. 大規模ファイルをハッシュ

10. 信任を得た起動- 1

11. 信任を得た起動- 2

12. 多重同期TPMダイジェストアルゴリズム

13. ログインパスワードの保存

14. 核心的信頼の基点の署名検証

15. 多重主キー

16. カスタム主キー

17. TPM引用キーの認証

18. 証明チェーンの作成

19. 鍵の承認にはデジタル署名が必要であることを保証

20. 鍵の承認には生体認証が必要であることを保証

21. 不揮発性データの保証

22. 不揮発性拡張インデックスに相当する引用

23. 機密情報の保存

24. 証明書の保存

25. 共通パスワードの保存

26. 基本的公開鍵の保存

27. HMACキーの保存

 

28. キーへのアクセスの取り消し

29. 多重ユーザーキーの取り消し

30. CAキー使用の監査ログの保護

31. 追加PCR

32. 異なる属性を持つPCR

33. 仮想化

34. ライトワンスの不揮発性インデックス

35. 標準認証

36. ライトワンス、リードオールウェイズの不揮発性インデックス

37. ポリシーシークレットの保護

38. キーの連鎖の複製

39. ハードディスク暗号キーをプラットフォーム状態に封印

40. VPNキー

41. OSがある環境からOSがない環境へ安全にパスワードを渡す

42. 引用

43. トランザクション間のリブートを検出

44. VM用の増加属性がないPCR

45. 監査用の増加属性がないPCR

46. 異なるユーザーのために異なるSRKを作成

47. 1台として動作するサーバセット

48. どのTPMに接続しているのか?

49. 不揮発性インデックス、カウンター、ビットフィールドインデックスはどういう状態か?

50. PCRとして使用される不揮発性インデックス

51. 認証機関として使用されるTPMの監査

52. TPMを使用してアプリケーション監査ログを保護

53. コマンドシーケンスの最中にPCRが変化しないことを確認

 

上記の事例をご覧ください。まず評価すべきは、TPMが起動プロセスだけを保護しているわけではないということです。上述したように、TPMは完全性の基点であり、一度にワンステップずつ、各ステップでATMの安全を図るうえで私たちがすべきことをさせてくれるのです。もちろん上記のユースケースの全てを私たちに適用できるわけではありません。また、これらのユースケースは暗号的に安全な方法で各項目を保護していることを覚えておいてください。

40番の「VPNキー」を例に説明しましょう。通常の使用では、VPNはATMとサーバ上にデジタル証明書(公開鍵)をインストールすることにより両システム(ATMとサーバ)の間に設定されます。しかし証明書に何者かが不正侵入したらどうなるでしょうか。TPMで保護されており、本白書でこれまでに述べてきたロックダウン機能を備えているWindows環境に保存されている証明書は、改変は不可能であるというのは事実です。しかし私たちはさらに一歩踏み込めます。VPNキーはTPMを使ってPCRに対する封印ができます。このことは、VPNが設定されようとしているときに、VPNの設定に必要なキーはPCRが適切な状態にある場合に限りを利用可能にできることを意味します。何らかの相違があれば、VPN接続は拒否されます。次にこのコンセプトがVPNトンネルの両側に適用可能かどうかを検討してみましょう。PCRはATM側で適切な状態にあることが求められるだけでなく、データセンターのATMサーバに対しても適切な状態であることを求めることが可能性です。それが実行されれば、ATMおよびATMサーバの両方が接続前に安全な状態になっていることを暗号上確認できます。その時点までにATMおよびATMサーバの両方で実行可能なすべてのソフトウェアは汚染も改ざんもされていないことを私たちは知っており、両システムがそのシナリオの要件を満たした場合、そしてその場合に限って両システムの接続を許可します。

本白書は、eBookのすべてのアイディアについて議論することを求める場ではありません。実際に、特にATMに適用される事例がこのほかにもあり、議論、設計および導入が必要です。ATM業界が業界内の場合によっては複数の委員会を通じてそれを実行するよう期待します。詳細は後述します。

ネットワーク接続の保護

すでにネットワークの保護について述べました。これはATMにとって特に重要な事例なので、もう少し詳しく述べておきます。ATMが個別に保護されることを望むだけでなく、私たちが触れるバックエンドサーバーシステムも安全で危険にさらされていないことを私たちは求めます。下図をご覧ください。

 

tpm diagram 2

 

上図は複雑なATMサービスを提供する一般的な大手銀行の接続図です。ATMは複数のバックエンドサーバとのやり取りを統合するターミナル・ハンドラ(フロントエンドプロセッサー)に接続します。HSM(ハードウェアセキュリティモジュール)はピンゾーニングを行い、暗号サービスを提供します。取引が実行され、その承認が求められると、モジュールはバンキングシステムに「自行」取引かどうかを、あるいは、カードスキームに「他行」取引かどうか問い合わせます。

そこで、全てのATMとサーバがTPMを搭載しており(最新のハードウェアは全て搭載)、全てのシステムが起動時からPCR測定で検証され、全てのTLS接続およびVPNがTPMアン・シーリングされた証明書を使って設定され、それによって改ざんが行われていないことを暗号的に保証するという安全のユートピアについて検討しましょう。確かにユートピアです。2020年8月の時点でほとんどの銀行がこの安全水準を達成していないということは、嘆かわしい事態です。

ATMのハードウェアデバイスの接続を保護

 

本白書はここまで、ATMのPCコアと、ソフトウェアが起動後の稼働中マルウェアの影響を受けない確実な方法に焦点を合わせて論じてきました。次にATM内の個々のデバイス、すなわちカードリーダー、ピンパッド、そしてもちろん現金自動払い機について見て行きましょう。PCコアと個々のデバイス間の接続で、安全な状態とは何でしょう。ほとんどのATMで、デバイスはUSB接続されており、物理的に改ざんが可能です。接続されたデバイスに暗号化されていないデータがあれば、たとえマルウェアが存在しなくても攻撃に対して脆弱です。図を使ってもう一度チェックしましょう。

tpm diagram 3

 

ご覧のように、攻撃リスクを示すために不安材料にUSB接続を用いました。TPMがPCコアを保護していますが、USBケーブルは保護がない限り攻撃されるリスクがあります。ほぼ間違いなく、この接続を保護するのはATMハードウェアベンダーの責任です。しかし状況はそんな単純ではありません。ハードウェアデバイスと、システムのその他の部分との間の相互運用要件にも左右されるためです。例えば、CDM(出金機)へのメッセージが終端間で暗号化されている場合、「もう一方の端」はどこなのか。例えば、もう一方の端がターミナル・ハンドラで終了している場合、多くの相互運用要件を議論し、考えを一致させる必要があります。

また、多くのATMで現金自動払い機でさえ十分に保護されていないことは明らかです。様々な「ブラックボックス攻撃」をマスコミ報道で目にします。ATMブラックボックス攻撃は、ハッカーが出金機への接続を横取できた時に、彼らは自身のPCコアを使って出金動作を実行します。最近のATMはほとんどがPCコアから出金機までの接続を暗号化していますが、一部のATMはTPMを搭載していないため、セキュリティ設計には多くの改善余地があるとKALは考えています。はっきりさせてみましょう。TPMのないところにセキュリティはありません。魔法で保護されたキーを使って接続を暗号化するというあいまいな方法は、セキュリティではありません。それはあいまいなことであり、願望にすぎません。ハードウェアベンダーが、暗号キーがどのように保護されているかに関する情報を公表できない場合、それは鍵がが適切に保護されていないためであることは明らかです。

XFS4IoTおよびハードウェアデバイスの保護

ATM業界のXFS委員会が、次世代のATMデバイスをどう保護すべきかを議論していることは朗報です。XFS4IoTと命名されたXFS 4.0が、まもなくリリースされることを聞いている読者もいると思います。末尾にIoTを入れたのは、仕様を最新のIoTの世界に対応させる意図を示しています。XFS4IoTにはいくつかの大きな目的があります。


1. 仕様はOSに依存しない。このことは、ATMはその内部にWindowsでも、Linuxでも、その他のOSでも搭載できることを意味します。
2. クラウドフレンドリーである。ATMデバイスはクラウドに直接サービスを提供することができます。ATMの制御部は、現在はATM内にありますが、これをクラウドに配置することができます。例えば、カードリーダーサービスをクラウドに提供できます。出金機は、そのサービスをクラウドに提供できます。
3. このように提供しているWebサービスを保護する必要があります。XFS4IoTはセキュリティ機能を内蔵し、各デバイスのエンドツーエンドのセキュリティを確保します。両端で証明書付きTLSによって保護されたWebSocketとして、トランスポートプロトコルが選択されています。さらに、各XFS4IoTデバイスは、ハードウェアを保護する要素を搭載でき、接続時のエンドツーエンドのセキュリティを可能にします。接続は、(現在と同様に)ATM自体内で終結させることも、クラウドサーバー上で終結させることもできます。

下図にコンセプトを示します。

tpm diagram 4

デバイスがPCコア上のソフトウェアアプリケーションに接続する場合、あるいは安全なサービスを上図右のようにクラウドに提供する場合、XFS4 ATMは上図左のような従来型ATMと同様に設計できます。2番目のケースでは、ATM内にPCコアは全く存在しない場合があり、各デバイスは互いに完全に独立していますが、物理的に接近しており、クラウドアプリケーションによって相前後して動作し、統合されます。

最も注意が必要なのは、「HSE」と書かれた緑色のボックスです。HSEは「hardware secure element(ハードウェアを保護する要素)」の頭文字で、もちろんXFS仕様では、ハードウェアベンダーがその最適な搭載方法を決定できるようになっています。HSEがTPMになるか、またはTPM機能のサブセットを含むかのいずれかを必要としていることは明らかです。最低限として、HSEは下記を実行できなければなりません。

  • 秘密鍵を安全に保存する
  • 安全なファームウェアのみがHSEを使用できるよう、基本的な「完全性の基点(CRTM)」を搭載する
  • 暗号化および署名サービスを搭載する

KALはこの点をTCG委員会と協議しました。同委はATM業界が選択肢をブレインストーミングすることを喜んで支援すると述べました。実際に、TCGはすでに「ミニTPM」というコンセプトである程度の進展を見せています。一つはTCGのDICE設計、もう一つはTCGのMARS設計です。DICEとMARSはATM業界で利用される準備ができているのでしょうか。確認する必要があります。

標準TPMは各デバイス内でHSEとして使えるかどうかという考えがありますが、興味深い考えです。コストの観点からは答えはイエスです。TPMのコストは、OEMボリュームで1米ドル未満です。DICEはもっと安くなる見込みです。消費者の資金を何百万ドルも保護している私たちの業界にとって、TPMや他のタイプのHSEのコストは妨害物にはなりにくいと考えられます。

ATMには第二の完全性の基点がある – それはEPP

上記の節でデバイスの保護について論じましたが、セキュリティの観点から注目すべきユニークなデバイスが一つあります。それはEPP(暗号化ピンのパッド)です。EPPは事実上、ATM内にある独立した完全性の基点です。それは高度に安全であり、PCI PED要件を通じて制御されていますが、各EPPは業界によって世界基準で個別に管理され、監視されています。それ自体のファームウェアを測定するCRTM機能を持ち、改ざんが検出されると、自動消滅します。これは実に安全なシステムです。

しかし業界には賛否両論があります。EPPはATMに一定レベルのセキュリティを提供するので(この後その限界を論じます)、銀行はこれに依存してATM取引を行ってきました。EPPは銀行のマスターキーを安全に保管し、暗号化された暗号化鍵を使ってピンブロックを確実に保護し、ATMとホスト間の通信電文を暗号化およびMAC認証します。これは適切なセキュリティですが、十分とは言えません。

EPPはATMが起動しても、WindowsおよびXFS SP(ATMのハードウェアドライバ)が立ち上がるまで使用できません。このことは、EPPはATM内のソフトウェアの有効性について何も言えないことを意味します。マルウェアに感染したATMアプリケーションが暗証番号の受領を要求したり、ATMホストへのMAC電文を要求した場合、EPPはその要求に従います。EPPの保護領域はあまりに小さく、ATM全体の保護には役立ちません。TPMが存在しない場合、それは大量にある潜在的な無保護ソフトウェアの中の飾り物にすぎません。

TPMで保護されたソフトウェアの更新法

読者の皆さんはここまで読んでおそらく、TPMで保護されたATM内のソフトウェアに変更を加えるのが無理なら、ソフトウェア更新を有効に行うことは困難だと考えていると思います。ソフトウェアアプリケーションは証明規則を使って保護されていることを思い出してください。それはアプリケーションの開発者(銀行自身、または銀行が信頼するベンダーの場合があります)によって署名されています。更新されたソフトウェアに必要なのは、ソフトウェアを開発した組織の安全な秘密鍵で署名されることだけです。そしてATMはこれを承認します。それほど簡単なことです。

PCRが測定したコアソフトウェアの変更には追加のステップが必要です。コアソフトウェアは技術者が現場にいなくても、リモートで完全に更新できますが、変更されていないPCRに対してシールドされる一時的な鍵がインストールプロセスの間に生成される必要があります。インストールが完了すると、新しい鍵はPCRのフルセットに対してシールドされます。簡単です。

前述したWindows Helloの例を思い出してください。優れたセキュリティは、使用が難しい必要はありません。実際に、ワールドクラスのセキュリティ(それこそTPM保護が銀行に提供するもの)は従来の方法に比べて、より簡単に使え、暗号的に安全です。

物理的攻撃に対する防護

明確に述べてはいませんが、これまでの議論の多くは、物理的攻撃およびソフトウェア攻撃からATMを保護することについてのものでした。ATMへの攻撃に共通する方法は、ドライブの除去、ソフトウェアの改変、当該ATMおよび他の複数のATMへの改変の復元です。ドライブが暗号化され、起動チェーンがTPMに保護されていれば、こうした攻撃は不可能です。

もう一つの攻撃方法は、TPMに対して様々な鍵を素早く連続的に「片端から試す」試みです。TPMにはこれを阻止する「ハンマリング対策」が組み込まれています。

最後に、極端なタイプの攻撃があります。それはマザーボードの電子回路に直接干渉する可能性のある攻撃です。このような攻撃には専門的な装置が必要で、実行には多額の費用がかかります。私たちが知る限り、発生した例はありません。ただし、こうした攻撃には低コストで対応する方法があります。マザーボード上で露出している電子回路接続部を、レジンを使って保護することです。

魔法のソリューションに注目

これまでに周知され、公表されたコンピュータシステムを保護する方法の中で、完全な方法は、完全性の基点としてのTPMでATMとPCを保護する方法だけです。この業界は、ATMネットワーク上になぜTPMによるセキュリティがもっと普及しないのかを自問する必要があります。もちろん様々な会社が市場で競業することを望んでおり、セキュリティ市場での地位を得たいと考えています。それは予想されることです。しかし銀行が非現実的なソリューションに騙されないことが重要です。下記は注意すべき事項のリストです。

神話:「ハードウェア保護素子は必要ない」

ATMのディスク/SSDに秘密鍵を安全に保存するのは不可能であることは疑いの余地がありません。理由は、鍵の連鎖がどんなに長くても、最初に暗号化されていない鍵を持たなければならないからです。その鍵をドライブに「隠しても」、いつでも回収できます。起動時にキーを生成できると断言するソリューションもあります。しかしその鍵を生成するには暗号無きコードが必要であることを思い出してください。ドライブをまだ復号化していない、暗号化されていない状態にあることが必要です。もしそれが暗号化されていない状態なら、ドライブを復号化する前に暗号化されていない状態になる実行可能なコードからそれを簡単にリバースエンジニアリングできます。

これを別の方法で考えてみましょう。もしソフトウェア技術だけでATM内に鍵を安全に保管できるとすれば、私たちの業界はEPPなどを構築する苦しみを経験せずに済んだでしょう。

神話:「ネットワーク上にキーを保存しているのでハードウェア保護素子は必要ない」

TPMがないためにATMが十分な安全性を確保しておらず、鍵を安全に保管できない場合、キーをネットワークの場所に移動しても問題の解決になりません。ATMの起動時にネットワークに接続し、安全鍵を取得する必要があるからです。またATMは鍵の保存場所を持っていないため、ネットワーク上でそれ自体が本物であることを証明する安全な暗号技術はありません。このことは、ネットワークサーバは「誰が鍵を要求している」のかを知らないことを意味します。例えば、Bitlockerがネットワーク上に鍵を保存した場合、TPMがネットワークに対し自身が本物であることを証明する必要があります。TPMのないところにセキュリティなしです。

神話: 「暗号化鍵は必要ない」

そのベンダーは、鍵を用いずに暗号化できる魔法の技術を持っているから、鍵の保存は必要ないと断言します。それが本当なら素晴らしいことです。鍵が必要ないなら、なぜ世界中が絶えず鍵管理技術に悪戦苦闘してきたのでしょうか。3DES、AES、RSAなど、知られている暗号化技術はすべて、秘密鍵を必要とします。秘密鍵は安全に保存する必要があると言われています。暗号化システムの安全を確保するということは、鍵を膨大な数の可能性から選択することです。例えば、3DESは少なくとも2112個の鍵を持ちます。毎秒50億個のキーを試しても、全てを処理するには30年を要します。AESを使って同じ速度で試すと1022年必要です。

神話:「自分たちのアルゴリズムは極秘である」

実際のセキュリティは、秘密鍵と共にオープンスタンダードおよびオープンアルゴリズムの上に築かれています。セキュリティシステムで唯一秘密にしなければならないのは鍵です。鍵が危険にさらされた場合、これを変更すると、システムは元通り安全になります。

神話:「アクセスコントロールリスト(ACL)があれば安全」

アクセスコントロールリストは、TPMロックダウンがなければ簡単に回避されます。ここで掘り下げて論じるつもりのないその他多くの様々な欠点がACLにはあります。ACLだけでATMを保護するには能力が不十分だと言うだけで十分です。


結論

TPMがなぜコンピュータセキュリティにとって極めて重要なのか、したがってATMのセキュリティにとっても極めて重要であることを、読者の皆さんは正しく理解できたことと思います。またほとんどの銀行が暗号化によってセキュリティを保証する形で、ネットワークを保護する方法をまだいくつか持っていることも明らかになったと思います。またこのようなセキュリティシステムはいずれも、相互運用性を考慮して設計する必要があることに注意することも重要です。最近のATM 技術の流れは、複数ベンダーと複数ソリューションがある程度標準化しているため、ロックダウンを目的に各ベンダーから単独で導入することは不可能になっています。そのようなことをすれば、利用できないATMが生まれるでしょう。

私は、本白書がきっかけで、私たちがTPMから利用できる暗号化技術の基礎を活用して、相互運用可能なセキュリティ仕様が開発されることを期待します。Trusted Computing Groupは私たちに協力してくれています。今や、設計の道を前へ進めるかどうかは、銀行およびベンダーと共に私たちの業界の様々な委員会(XFS4IoT、ATMIA、EASTなど)にかかっています。

謝辞

本プロジェクトに協力いただいた下記の人たちに感謝いたします。

      • Michael Moltke (NCC Group Denmark)
      • Kit Patterson (KAL)
      • TPMに関してeBookに執筆したWill Arthur、David ChallenerおよびKenneth Goldmanの各位。David Challenerは、TCGからのサポートの企画、実行でも協力していただきました。 

詳細については、このメールアドレスはスパムボットから保護されています。閲覧するにはJavaScriptを有効にする必要があります。までメールでお問い合わせください。