セキュアエレメントへのレーザーフォールトインジェクション

Black Hat USA 21にて、Microchip ATECC608Aを対象としたレーザーフォールトインジェクションの事例が紹介されていたので翻訳しつつ洞察してみる。

元資料はOlivier Hériveaux氏の[” Defeating a Secure Element with Multiple Laser Fault Injections”](https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-Defeating-A-Secure-Element-With-Multiple-Laser-Fault-Injections.pdf)となる。
同氏は暗号通貨のハードウェアウォレットを提供するLedger社のセキュリティチーム「Ledger Donjon」所属である。

また詳細な論文が同氏発表で[SSTIC2021](https://www.sstic.org/media/SSTIC2021/SSTIC-actes/defeating_a_secure_element_with_multiple_laser_fau/SSTIC2021-Article-defeating_a_secure_element_with_multiple_laser_fault_injections-heriveaux.pdf)で発表されているので併せて読んでいく。

#アプローチ

2020年に同氏がColdcard ハードウェアウォレットMk2に搭載されているMicrochip ATECC508Aをレーザーフォールトインジェクションで調査した際に、攻撃者が秘密データスロットを読み取ることができる脆弱性を発見した。その後、本チップの製品ライフサイクルは非推奨となり、より安全であるとされるATECC608Aが後継機種となった。
今回、同製品を採用したColdcard ハードウェアウォレットMk3を用いて、この新しいチップのデータスロットの機密情報を取得するための新しい攻撃方法を紹介している。
この攻撃では、セキュアエレメントで保護されたシークレットシードを盗むことができた。

この試みは攻撃者が内部ハードウェア情報、ファームウェアのソースコードを入手できないブラックボックスアプローチで実施され、電源トレース解析とReadコマンドの中で最大4つのレーザーフォールトインジェクションの助けを借りて、攻撃経路の特定プロセスを説明する。その結果に基づいてファームウェア実装の仮説を構築し、課題と対策を考察している。


#前提

前回のATECC508Aの検証で、レーザーフォールトインジェクションに対する対策（例えば光検出器）の機能がないことがわかっているのと、ATECC608Aがハードウェアデザインを大きく変えたものではなく主にファームウェアの強化と仮定して継続してレーザーフォールトインジェクション手法を用いている。

また、ATECC608Aの持つデータ保持方式のスロットに対して、アクセス制御を行うコンフィグがあるが、
以下の通りのスロットに対して攻撃を行う想定。
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387653/e57cb257-7081-0b22-0e21-76451cf484b4.png)
この中の読み取り制限を行う”Is Secret”ビットをターゲットにする。
ここで合わせて“Encrypt Read”がFalseになっていることで、暗号化されていない平文でデータを受け取れることを想定する。


#試行内容

障害をいつ注入する必要があるかを見つけるために、メモリの読み取りコマンドが受け入れられるか拒否されるかどうかの動作の違いを検出するために、差動電力分析(DPA)を実行しました。
Readコマンドが成功した呼び出しと拒否された呼び出しの間の実行パスが363µsで異なることがわかります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387653/8fe55c3c-2de7-24d8-cbc4-ab612cb0513f.png)

成功した呼び出しと拒否された呼び出しで、差分が出始めたタイミングに、”Is Secret”のチェックがあると仮定し、ATECC608Aのチップへアクセスし、”Is Secret”に相当するEEPROMの特定の場所をレーザーフォールトインジェクションでビットを0にし、攻撃を試みた。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387653/4ea130cc-476d-24d4-0c66-a9d487dcc21f.png)
機材は[ALPhANOV（アルファノブ）](https://www.alphanov.com/en/products-services/double-laser-fault-injection)のもの。フランスに拠点を置く国営研究機関
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387653/08782edf-01bd-a037-b1ba-ebf7d0d5b16c.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387653/d5da6214-bf0d-54ec-896f-b9eb39bf747b.png)
するとうまく動作をだますことができ、成功した呼び出しの動作に追従が進んだが、少し進んだところで
また差分が出始めたので、差分の地点で成功した呼び出しの動作に追従するようにもう1か所レーザーフォールトインジェクションを追加した。
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387653/fe621457-e107-6f1b-2e08-7d0e5f4bcc58.png)
2回のレーザーフォールトインジェクションで追従が進んだが、差分が発生、ダブルチェックを行っていると仮定し4回のレーザーフォールトインジェクションを配置したのが下記。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387653/890f4dd1-c758-ea63-2acf-fdb59d2e6034.png)
これでReadコマンドの成功した呼び出しが完了し、値が返ってきたが、想定した値と違うものが返ってきた。この方法は失敗に終わった。

#再度の試み
”Is Secret”ビットを反転させ、読み出しに成功した値は想定と違っていた。
これを何らかの暗号化が付加されていると仮定した。
別途用意されているAES機能を実行し、電力トレースを確認すると以下の通り。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387653/76de1b16-a6b3-bbfe-88d8-c252c450a174.png)
10個のAES計算を行っているパターンが観測された。この形をもとに、Fig.7のアクセス拒否された波形を見ると類似した部分が観測される。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387653/e9079656-cb32-d4c7-8831-fe23b375c311.png)
このことから、以下のような疑似的な内部処理を想定できる。


```
int internal_get_slot_data ( int slot , char * dest ){
    uint16_t config ;
// Don ’t fault here :
    eeprom_read ( get_config_address ( slot ), & config , 2);
    if ( config & IS_SECRET ){
        char encrypted [32];
        eeprom_read ( get_data_address ( slot ), encrypted , 32);
        aes_decrypt ( encrypted , dest , SOME_INTERNAL_KEY );
    } else {
        eeprom_read ( get_data_address ( slot ), dest , 32);
    }
return OK;
}

void read_memory_command ( int slot ){
// Command arguments checking
// During attack campaigns , some faults produced PARSE_ERROR
// responses .
if (! slot_valid ( slot )){
    i2c_transmit ( PARSE_ERROR );
    return ;
}
uint16_t config ;
// First Access condition checking
// Fault EEPROM access here :
eeprom_read ( get_config_address ( slot ), & config , 2);
    if ( config & IS_SECRET ){
        i2c_transmit ( EXECUTION_ERROR );
    return ;
}
// First data fetch
char buf_a [32];
internal_get_slot_data (slot , buf_a );
// Second access condition checking
// Fault EEPROM access here :
eeprom_read ( get_config_address ( slot ), & config , 2);
    if ( config & IS_SECRET ){
        i2c_transmit ( EXECUTION_ERROR );
    return ;
}
// Second data fetch
char buf_b [32];
internal_get_slot_data (slot , buf_b );
// Double read checking
    if ( memcmp ( buf_a , buf_b )){
        i2c_transmit ( EXECUTION_ERROR );
    } else {
        i2c_transmit (OK , buf_a );
    }
}
```


最終的に、AES動作が有効になるようにレーザーフォールトインジェクションを2回に減らし、Readコマンドの成功した呼び出しが完了し、得られた値が期待するものであった。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387653/904c386d-6d02-b7ea-a920-0be5465c7b4c.png)
潜在的に暗号化して書き込みを行っているという機能の存在を解読に逆用されてしまった形になる。

#洞察

著者によると、ATECC508Aからの継続したテストが、今回のATECC608Aの解析に力となっている。
また、ATECC508Aのテストで言及されているが、スロットの設定によりPrime256のEC秘密鍵の保管を行う目的、すなわち通常のIoTデバイスでの利用シーンでこの脆弱性が有効なわけではなく特定のスロット設定の際にリスクになるということだ。

ColdcardがATECC608Aをどのように利用しているか詳細は不明だが、直接的な経済的価値のあるハードウェアウォレットとしては、デバイスを悪意のある者に窃取された場合、こういった高度なフォールトインジェクションが行われ、この脆弱性を利用されることが想定される。

著者が提言する対策として利用者側で参考にできるものとしては、後継品のATECC608Bを使用するという点である。ここはハードウェアライフサイクルとしては課題になってくるだろう。

ハードウェアウォレットとしての用途ではなく、セキュアエレメント全般の通常のデバイス認証、セキュア機能利用の観点で考えられることとしては以下のように考えられるだろう。

* 読まれて困るデータを外部から置かない。
* もし外部データを置く場合、スロットに対して、アクセス制御を行うコンフィグについて十分にテストを行う。
* 用途を限定する。（秘密鍵の保管）

あとはセキュリティ対策の組み合わせでターゲットとなることを防ぐ、なったとしてもその対策のハッキングと対価の経済効果に見合ったレベルの実装を行うという基本セオリーが有効と考える。