身近な汎用のコンピュータの内蔵ディスクがHDDからNAND型フラッシュメモリ（SSDやeMMC）に移行して久しいが、あらためて内蔵ディスクの残存データの取り扱いについて考えたい。
デバイスの特性に基づく考え方の変化については、HDDからSDDへの移行期に語りつくされたように思うし、当時の議論については2023年現在も引き続き有効だと考えている。
それとは別に1点：特にスマホ等で顕著だが、最近はNANDメモリやeMMCがコンピュータ本体のロジックボードに直付けされていることも多い。あと筐体の分解難易度が確実に上昇している。
つまり、内蔵ディスクを取り出すことが容易ではなくなった。この点も残存データの取り扱いに影響を及ぼすように思う。
おさらい (1)：そもそも「消したはずのデータ」が残っている可能性は？
OS上でファイルを削除した時、HDDの場合、ファイル管理領域の情報だけ削除されて、データ領域のセクターにはデータが残存している――という点がHDD時代のデータ消去事情の根底にあった。
SSDが使われるようになって生じた変化は、Trim/UNMAPの登場だろう。OSがファイルを削除した時、使わなくなった領域の情報をSSDに通知することで、SSDが当該領域に該当するブロックのデータを消去する――という仕組みである。
最近のOSにはTrim/UNMAPを発行する機能があるし、SSD側もTrim/UNMAPに対応している。つまり、削除したファイルのデータが、Trim/UNMAPによってNANDメモリからも消えている可能性がある。
問題は、NANDブロックのデータ消去はそれなりに時間がかかる（その分だけファイルI/Oの性能に影響が出る）処理であるため、OSやNANDフラッシュメモリコントローラが色々と賢いことをやっている、という点にある。
OSは、ファイル削除の度にTrim/UNMAPを発行する訳ではない。バッテリー駆動などの省電力モードではTrim/UNMAPを全く発行しないこともある。コントローラも、性能低下を避けるために、Trim/UNMAPを受けたタイミングとデータを消去するタイミングが異なる可能性がある（コントローラのファームウェアのアルゴリズムに依存する）。
HDD時代ほどあからさまではないものの、SSDやeMMCにおいても、OS上で削除したファイルの中身のデータがNANDメモリのブロックに残っている可能性がある、と考えてよいだろう。厳密にはOSやコントローラの振る舞いに依存する話になりそうだが、コントローラなんて（ファームウェアのバージョン違いまで考慮すれば）山ほど種類があるのだから、個別対応じゃなくて最悪のケース――データが山ほど残っている可能性を想定した方が安全だろう。
USB接続のデバイスの場合、もう少し複雑になる：
- UAS (USB Attached SCSI) 未対応なら、Trim/UNMAPにも未対応である。
- UAS (USB Attached SCSI) に対応していれば、Trim/UNMAPに対応できるはずだが：
2023年9月の時点では、USBメモリやUSB-SSDについては、Trim/UNMAPの効果には期待しない方がよいだろう。HDDと同様に「残存データがある」という前提で考えるのが無難だ。
おさらい (2)：NAND型フラッシュメモリの特性と残存データ対策
NAND型フラッシュメモリの残存データを何とかしようとしたら、次の2択しかないだろう。
NAND型フラッシュメモリはコントローラとセットで用いられる。この点が事を複雑にしている。
HDD時代から用いられてきたデータ消去のアルゴリズムは、SSDやeMMCでは有効ではない。HDD向けのデータ消去では、データが残存しているセクターにたいして無意味なデータを上書きしている。フラッシュメモリでは、データ書き込みはコントローラ経由で行われるが、コントローラはウェアレベリングやBad Block管理も踏まえた動作をする。そのため「残存データのあるブロック」にデータが上書きされることを保証できない。
フラッシュメモリのブロックの残存データを消すには、俗に言うSecure Eraseを実行することになる。ATA CommandやNVMe I/O Commandにはデータ消去に使えるコマンドがある。データ消去のコマンドをデバイスにたいして発行すると、デバイスが対応していればデータが消去される。
コマンドを受けて処理を実行するのはコントローラだろうから、コントローラがデータ消去のコマンドに対応していて、コントローラがちゃんと動作してくれれば、データが消去されるはずである。
言い換えれば、次のケースでは、データが消去されない可能性がある。
- コントローラがデータ消去のコマンドに対応していない、または対応しているふりをしているだけ。
- コントローラのデータ消去関連の機能に不具合がある。
- コントローラが壊れかけていて、データ消去関連の機能に支障が出ている。
- コントローラが故障していて、動作しない。
一般的に、NANDメモリを自社製造しているような大手SSDメーカーの製品は、メーカー公式のデータ消去ツールも存在することから、コントローラを含めてデータ消去のコマンドに対応していると考えてよいだろう。だから、デバイスが正常ならば、データ消去を期待しても大丈夫なはずだ。でもデバイスが妙な振る舞いをするようならば、コントローラが壊れかけているかもしれないので、ツールによるデータ消去は期待せず、NANDメモリチップを物理破壊した方が安全だろう。
大手メーカー以外の、有象無象の格安製品では、最初から物理破壊するべきだろう。そもそもNANDメモリだけでなくコントローラも偽造品かもしれないので、Secure Eraseに期待しない方がよい。
さて、ATA CommandやNVMe I/O Command云々は、内蔵ディスクとして用いるSSDやeMMCの話である。
USB接続のデバイスの場合、もう少し複雑になる：
- UAS (USB Attached SCSI) 未対応なら、Secure Eraseする術がない。
- UAS (USB Attached SCSI) に対応していれば、SCSI Commandのデータ消去のコマンドが使えるはずだが：
少なくとも、2023年9月の時点では、USBメモリやUSB-SSDのデータ消去は、あまり期待すべきではないだろう。まあ、一般的に外付けデバイスは物理破壊しやすいことが多いのだから、最初から物理破壊を試みてもよい気がする。
おさらい (3)：NAND型フラッシュメモリの残存データの復元難易度
仮にSecure Eraseを期待できないデバイスが故障したとして、残存データを吸い出されて復元される可能性は、どの程度あるだろうか？
まず、NANDメモリ自体が故障・破損している場合、残存データの吸い出し自体が難しいだろうし、仮に吸い出しに成功したとしてもデータ自体が損傷していると思われる。
次に、NANDメモリは生きているがコントローラが故障している場合、全く同じコントローラ（型番だけでなくファームウェアバージョンも同じもの）に差し替えることで、データを吸い出せる可能性がある。ただし、そもそも「型番もファームウェアバージョンも同じコントローラ」を入手すること自体が難しい、ということは考えておくべきだろう。
コントローラを経由せずにNANDメモリからデータを吸い出した場合、吸い出したデータから「意味のあるデータ」を復元するのは難しい。そもそもコントローラがウェアレベリングやらBad Block管理やらと色々と配慮したアルゴリズムによって分散したブロックにデータを書き込むし、アルゴリズム自体がコントローラの型番やファームウェアバージョンによって異なる。データ復旧業者が「SSDのデータ復旧は難しい」と言う理由の一端である。
ただ、「意味のあるデータ」に復元するのは難しくとも、データ自体は吸い出される可能性があるし、曲がりなりにもデータ復旧業者が成り立つ程度には「データが復元される」可能性もある。
結局のところ、残存データの吸い出しと復元を気にするならば、NANDメモリ自体を破壊して吸い出し不可能にしてしまおう――ということになる。
デバイスが取り外し可能なら物理破壊が確実だが……
SSDやeMMCのデータ消去においても、HDDと同様に、物理破壊は非常に有効である。
であるのだが、HDDとは異なり、SSDやeMMCはコンピュータ本体の基板に直付けされていることがある。この点が「物理破壊最強説」に影を落としているように思う。
色々と考えてみた結果を表にするとこんな感じ：
| デバイスの取り外し | 本体／デバイスの生死 | 残存データ対策 |
|---|---|---|
| 取り外し可能 | 動作する | 物理破壊 or Secure Erase |
| 取り外し可能 | 動作しない | 物理破壊 |
| 取り外し不可能 | 動作する | Secure Erase or ？？？ |
| 取り外し不可能 | 動作しない | ？？？ |
デバイスが取り外し可能ならば、物理破壊が最強である。大手メーカーのSSDならばSecure Eraseも悪くないが、有象無象のSSDではコントローラの信頼性（Secure Eraseに適切に対応しているか否か）が怪しい。何よりも、デバイスが故障していたらSecure Eraseできない。
ではデバイスが本体の基板に直付けされていて取り外し不可能な場合はどうだろうか？
そのデバイスを搭載したコンピュータ自体が生きていて、なおかつSecure Eraseを明示的に実行できるならば、データを消去できるだろう。
では、デバイスを搭載したコンピュータが故障してしまった場合はどうだろうか？ あるいは、コンピュータは生きているものの、何らかの理由で「Secure Eraseが実行されること」を保証できないシステムの場合はどうだろうか？
デバイスを取り外し可能ならば、取り外して物理破壊することも、他のコンピュータに移植してSecure Eraseを試みることもできる。でもデバイスが基板に直付けだと移植は難しいし、筐体の分解も難しいならば物理破壊の難易度も高くなる。
最悪なのは、次のような事態である：
- 故障により基板直付けのSSD/eMMCにデータが残ったままのコンピュータを破棄した。
- 故障した部分は、NANDメモリやコントローラ以外だった。
- このコンピュータをジャンク品として入手した人が修理できてしまった。
- NANDメモリやコントローラは生きていたので、データを読み出せてしまった。
さてはて、いったいどうしたものか？
「どう頑張っても残存データは生じる」という前提に立つ――ディスク暗号化
Secure Eraseも物理破壊も難しい状況が考えられるのならば、残存データそのものをどうにかしようと頑張ることは不毛だろう。残存データが生じることを前提に考えるべきだ。
現時点で有効なアイデアは「ディスク暗号化」と「耐タンパ性を備えたセキュリティチップ」と「『複雑なパスワード』ないし生体認証」を組み合わせることだろう。
ディスク暗号化は、WindowsではBitLockerを、macOSならFileVaultを導入すればよい*1。ディスクを丸ごと暗号化しておけば、NANDメモリから吸い上げたデータより「意味のあるデータ」を復元したとしても、復元されたデータは暗号化されている。復号されない限り大丈夫だ。
復号用の秘密鍵が漏れないように、耐タンパ性を備えたセキュリティチップを備えたハードウェア使用すべきだろう。BitLockerはTPMと組み合わせるべきだ。macOSについては不明だが、T2セキュリティチップや、M1以降のSoCに統合されたセキュリティ機能は、おそらく耐タンパ性を備えているはずだ。
「ディスク暗号化」と「耐タンパ性を備えたセキュリティチップ」の組み合わせは、コントローラを経由せずにNANDチップから直接データを吸い出されるケースへの対策として十分に機能するはずだ。
その上で、NANDメモリやコントローラ以外の部分が故障していたコンピュータを修理されてしまった場合への対策として、簡単にシステムにログインできないように認証機能を有効化しておくべきだろう。
パスワードを使うならば、複雑なパスワードを設定しておくべきだ。生体認証（指紋認証や顔認証など）が使える機器ならば、パスワードではなく生体認証を選択してもよいだろう。Windowsでは、BitLockerのOS起動前認証を併用するのも良いアイデアだ。
機器を廃棄する時は、最低ラインとして「ディスクを暗号化した状態でOSを再セットアップ」すればよい。重要ファイルの残存データはNANDメモリに残っているが、暗号化されている。復号できなければよいのだ。
Windowsでは、OSの機能を使用してシステムを初期状態に戻せばよい。その際にTPMをクリアすれば、「『初期状態に戻す前に暗号化したデータ』を復号するための秘密鍵」が消えてなくなり、復号が困難となる。
macOSでは、FileVaultを使用した状態で、サポート情報（ここやここ）を参考に作業を進めればよいだろう。
取り外しが容易な内蔵ディスクでは、上記作業を行った後に、追加作業としてSecure Eraseや物理破壊を行ってもよいだろう。なお物理破壊の際にはNANDメモリのチップを狙うこと。
このアイデアの注意点は、例えばOSのシステムファイル破損などのソフトウェア要因でシステムが起動しなくなった場合に、USBブートさせたOSを使って重要ファイルを救出することが困難である可能性が高いことだ。
ディスク暗号化するならば、外部メディアへのデータバックアップと、バックアップ先メディアの安全な保管が欠かせないだろう。
まとめ
内蔵ディスクとしてNANDフラッシュメモリを使用する機器では、基板直付けで取り外せない可能性などを考慮すると、「残存データを何とかする」という方向性ではなく「残存データが生じる前提で対策を考える」という方向で考えておいた方がよいだろう。
現時点で有効なアイデアは、以下の3つを組み合わせることだ：
- ディスクを丸ごと暗号化する。
- TPMなどの「耐タンパ性を備えたセキュリティチップ」を使用する。
- 機器にログインする際の認証に「複雑なパスワード」ないし生体認証を用いる。
機器を廃棄する時は、ディスクを暗号化したままの状態で、「セキュリティチップに保存された秘密鍵の消去」と「OSの再セットアップ」を行えばよい。WindowsもmacOSも、標準のシステムリセットの方法が用意されている。
副作用として、故障時のデータ救出難易度が高くなるので、重要データのバックアップとバックアップ先メディアの安全な保管が欠かせなくなる点に注意すること。
なお、最終手段としての物理破壊は、SSDやeMMCでも非常に有効である。破壊する際にはNANDメモリのチップを狙うこと。
