前回の記事

この記事を内容を前提として今回は暗号の解読まで行いました。

自動販売機と古いEdyの決済時の通信を FelicaRelay で覗き見て平文に戻しました。

前回の記事ではSony の FeliCaカード ユーザーズマニュアル 抜粋版 を参照しましたが、今回は日本工業規格 JIS X 6319-4 を参照します。

JISの附属書B コマンドシーケンス例を大いに参考にしました。

FelicaRelay を挟んだ状態で古い暗号を使用しているampm時代のEdy（Edy No. 1001 9600 0087 8513）を使って残高1000円の状態から自動販売機で100円の飲料を購入しました。

20220723_5.txt

D:\Projects\FelicaRelay>python relay.py -t 1 -s fe00
TIMEOUT CARD     1.0 s
TIMEOUT READER   1.0 s
Scanning Devices...
DEVICE CARD      usb:001:005
DEVICE READER    usb:001:004
target_r 212F sensf_res=0101010601A603410A03014B024F4993FF801E
Tag Type3Tag 'FeliCa Standard (RC-S915)' ID=01010601A603410A PMM=03014B024F4993FF SYS=801E
Request System Code
801e fe00
Polling to fe00
idm pmm sys
<> {"idm": "11010601a603410a", "pmm": "03014b024f4993ff", "sys": "fe00"}
sensf_res 0111010601a603410a03014b024f4993fffe00
Emulator Start
target_e 212F sensf_req=00FE000000 sensf_res=0111010601A603410A03014B024F4993FFFE00 tt3_cmd=0211010601A603410A0DFFFF00000010011008100A11081210130A14081508160C170814
Initial Response
<< 250211010601a603410a0dffff00000010011008100a11081210130a14081508160c170814
>> 250311010601a603410a0d0000000000000000010001000100010001000100010001000100
<< 2a1011010601a603410a03000000100110080a11081210130814081508160c170810cb3ff0dbb02ae8f8
>> 1a1111010601a603410a785014dcbfe32c581c53c927f79c67b9
<< 121211010601a603410a99ec2d26ef27bb95
>> 2213a8d1f39f089767c6955a9fce06970dd3e0bf3db8ca0f220ba2607034a7bb8193
<< 22144065a72aec9df3d6dbf6eaab4bab8443369efaf943ff75d142022e42040eb42f
>> 8a15758c53e203682bc35c295dc8612ec766a21ca2a26d1522f098311c6997bb571b1c088c0cdb44a479c129b4c7504da2f82d64c0ba92ef77c6e0cbe05d929352d37695775764fae7cafa69255c917a000ea96294637d3610bdef144aeee1c9eca954e4c437bd90712ab1775931827179b2dcf2e673d1f05ff6510ab5c738eb31025be6c4721c3da1d8
<< 221467dea7014b15d2f98ef5ed2aa5520c18a5957d4be00732e23b40f1955308cfd8
>> 7a15e506ca377c8725aad429c7d4b7a6ebc138ebd8a7a002822e1a5ec5ab11c30b1e22ff9bd1e1d74c0802bdf56f37ead91f1e1f017416911465273fa10206198bf14f884bffd68900170da068c7c3486a3ca690b6a0296ca07e0803d64f713c0f056eefeff056e7f3c3c11121b16dec882a0a5b8caee0163a65
<< 221458de5cd963ddab3c7ad6326343c7bcaa3a73054ca0b3b1b118bca99280823e10
>> 7a15779ddcbf660ca90b7ef659a9bb6942ab4d02d40dfed340ddafb46b4677df1626e1871ab21e30503611e9a526d94c8493fb2b5503469d3fa9c84d893a2659a874427173dd34f7b66255e7b7504673a06badf0d67fe7ab7a716310f6d118ec4561017199ca0f9f5ffecf6cc33c50d1ed255995bd88cae74b12
<< 2214ca867f1eb5b848ea219687e194f71bc39f2aa27cfbaf578a000bbf68f504ad14
>> 7a1588bb0c4744cbdd393df4fd9ced17c02b86f5e3a7278190a7df60f543b453ca40a1792332e11db8045d52b7fb85908aca712754a292c84a9d60e3c7b315cf734e32b85b493bf40169ac9e94f1c7ddd0aaead2cb0d7d3cca993f6252589497b09979d7891518e57aeb67e5329135c4e9bd8362a51d22ca8e67
<< 0a0411010601a603410a
>> 0b0511010601a603410a02
<< 7216ee4a0f6a3049015aeec7d2ad5f5be6714e096a4391bace0122986b070f80efe856b1c471408ee3a3b44e7a90b85092ee30d085ba37d4ffad55be211ab5ce4bac06a89c0393faf8df6936656f754c71e960da6943f836d63e746d4b9c18993f3beb4420ddfc186ba477184502ceb42cac
>> 1a1725c17e407c3017a5f536e5783c9bb82d3f9b6f5fba3ae0f8
<< 22140d1ef97c80a8f6caf4e6d32628fe08ae934f489cb47e9418d22bd4a4c3537ebe
>> 6a159ee18a6c33ea68db46edfcda06a344545af9175a5483b1bf9d9f5ab1ac097037be3e9c24ffa9f174334a09a9c952fa80ac91c129cd216d58b17c49a7fbfbae62531a24707de3ab6d631afe8c204cb8ae5327b78845b28ff04139e959181bc9c585616d590837da94
Exchange Finished

D:\Projects\FelicaRelay>

この通信の鍵をNVIDIA A100 × 8台 と hashcat を使用して約40時間で解析しました。

復号部分は”{}”で囲みコマンド・レスポンスの意味に則って空白・改行を挿入しました。

20221008_20220723_5_plain.txt

key: 02fd45e69dc8bcce

Authentication2 Response
22 13 {0000 [IDc:d0a485cea30b] 0101bf0300009d07 0000000000000000}

Read Command
22 14 {0200 [IDc] 07 8700 8000 8001 8100 8200 8300 8600
01}

Read Response
8a 15 {0300 [IDc] 00 00 07
0000000000000000100a06cc0f62d63b
00011001960000878513077e00000011
000061a80000c3500000c35000000000
00000000000000000000000000000000
e8030000000000000000000000004000
00000000000000000000000000000000
020000403cf121db000003e8000003e8
0000000000}

22 14 {0400 [IDc]
06 8600 8601 8602 8603 8604 8605
030303}

7a 15 {0500 [IDc] 00 00 06
020000403cf121db000003e8000003e8
2000003f167b18f5000000b400000000
2000003e16730ae7000000e6000000b4
2000003d16650be6000000640000019a
2000003c161f096f000000d7000001fe
2000003b16110bfe00000064000002d5
0000000000}

22 14 {0700 [IDc]
06 8400 8401 8402 8500 8501 8502
030303}

7a 15 {0800 [IDc] 00 00 06
004002013cf121db00000000000003e8
9001830800001944000003e800030000
0000000000000000f0bec3d8c93d0db3
003f2000167b18f5000000b4000000b4
1011b99900006d9b0000000000030000
0000000000000000ba26ce60ce00861c
0000000000}

22 14 {0900 [IDc]
06 8600 8601 8602 8603 8604 8605
030303}

7a 15 {0a00 [IDc]
00 00 06
020000403cf121db000003e8000003e8
2000003f167b18f5000000b400000000
2000003e16730ae7000000e6000000b4
2000003d16650be6000000640000019a
2000003c161f096f000000d7000001fe
2000003b16110bfe00000064000002d5
0000000000}

72 16 {0c00 [IDc]
05 8200 8500 8501 8502 8600
84030000640000000000000000004100
00412000405e9128000003e800000064
c0089396000000430000038400030000
00000000000000000bb9c8042a59c859
20000041405e91280000006400000384
0505050505}

Write Response
1a 17 {0d00 [IDc] 00 00 000000000000}

22 14 {0e00 [IDc]
05 8200 8500 8501 8502 8600
0505050505}

6a 15 {0f00 [IDc] 00 00 05 
84030000640000000000000000004100
00412000405e9128000003e800000064
c0089396000000430000038400030000
00000000000000000bb9c8042a59c859
20000041405e91280000006400000384
0000000000}

IVはnullでCBCモードを利用して暗号化されていました。

何故かリーダからの通信はPKCS#5パディングなのにカードからの返送はnullパディングでした。

各通信の先頭ブロックには単調増加のカウンタ（2バイトリトルエンディアン）と6バイトのIDcがあり、末尾にはMAC（メッセージ認証コード）と推測されるものが付加されていました。

鍵の解析時の hashcat のオプションは以下です。nullパディングを推定し（なぜ？TODO）Write レスポンス部分を使用しました。

./hashcat.bin -m 14000 -a 3 --hex-charset --session=20220723_5_null -o key.txt --outfile-format=3 -w 4 -1 charsets/DES_full.hcchr f536e5783c9bb82d:25c17e407c3017a5 ?1?1?1?1?1?1?1?1

これでわかるのは通信鍵（セッション鍵）なのですが、丸一日半で解析できる手前、自動販売機に3DESで相互認証をさせて相互認証状態を維持したまま通信鍵を解析すれば任意のコマンドをカードに送れる気がします。FeliCa が堕ちる日も近いですね。

ただし MAC （メッセージ認証コード）（各種資料には単に「パリティ」と記載されているため単純なチェックサムの可能性あり）の生成方式は現在まで不明です。面白いパズルをみすみす手放すのも悔しいですが、ここは皆さんの集合知に任せます。方式が分かったら一報ください。