PKCS7切り離された署名ハッシュの解析
Apple iOS Passbookファイルの署名を手動で確認しようとしています。これは、Apple開発者のRSAキーのPKCS＃7分離署名ですファイル。
これは、「manifest.json」ファイルの分離された署名である「signature」ファイルがあることを意味します。私は http://www.flonsolutions.com/fantastic_voyages.html の新規の「タイタニック搭乗券」pkpassファイルをテストに使用しています。実行：
openssl smime -verify -in signature -content manifest.json -inform der -noverify
成功して戻ってきたので、署名が有効であることを知っています。これで、signatureファイルを解析して、DERエンコードされたASN.1データをデコードでき、署名されている属性がメッセージのSHA1ダイジェストであり、結果として733538fde88843c7ad24fb71674dbdd372df7b4d1になることがわかりました。 openssl sha1 manifest.jsonを実行すると、そのファイルのSHA1が確かに7335...b4d1であることがわかります。
次に、SignerInfoのsignatureビットを解析して、署名のRSA暗号化であるOctetStringを取得します。
BC C5 F9 F2 53 FD 2C 13 EA CE 64 BB 89 85 60 82 78 63 5B 04 FA F8 BF 7E 2A 6C 20
5D C3 C8 E8 8A 2F E3 4D B9 8E 1C A1 42 DF 2B 46 89 76 63 0B 8A DD E5 8A 69 4E D0
CF 3F E7 36 1E F8 7F 49 0D 27 EC 0F 73 76 5D 62 A1 4E 8A 43 AB EC ED 2E CD E7 69
3F AD 32 48 0A 79 52 DB 36 5B 61 94 71 3F B3 09 1E 80 17 94 31 06 AF E6 A3 A5 A0
D6 B7 71 31 ED 4C 6F C1 5C B6 4B 79 E5 7A BA BC 1D AD BB D2 F7 39 05 16 73 2C AE
74 E3 9C 4F 7E A7 B1 90 38 FC 92 78 9F 70 C0 D0 94 83 83 EC 01 F4 B6 16 36 4B EE
BC BA DD AC 23 64 4B C2 93 21 9E 9B 21 64 9E 7C 1B 72 87 0B C1 7D 9C 6A 9B AA AB
36 67 F8 7C 7B 8D 9E 88 FC 95 C8 29 57 8B EB B9 5C F6 AB 59 64 CA 87 ED DE 50 BA
67 C0 26 F8 5B FD 47 10 B0 A6 4E D8 D6 F0 E9 A0 DE 2B 6B D4 84 2A 91 A6 A7 27 22
CE D6 5F D2 C7 87 56 A4 E6 E4 D6 D3 C9
以前のsignatureファイルの証明書の公開鍵を使用する：
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzEjQiB/QgOWX2QF6CGtCiq1ZDyRzJJKJ
4ZW6cuF2MdtOi4If+IhTHcVkdeJ+/cacuRFcscNOXODjriCbAbmTVYTFx290n4vQ1qvPuu3/T41f
4dZHvAM9dmUHuN7M/f/SyGWJiFSYj3VY7S+jyH5zvskGp84YNkHB/Uky3ZFZElOwoOltRNVL25Rw
52nIMVrqO+Cyn2T2LSkk/6yjSll46TyjYuTDEev4XvYhIQBfbraP9rUabRkf1k0EuXl7qM2GeKGM
vq9sQwMRPVFFM2Fa/8xUeA4D/4AWR4S4shuVUxWOx8bq57RNRDogTr4rotaAOyDACu0aS37fWJmQ
zExr3QIDAQAB
-----END PUBLIC KEY-----
RSA暗号化を正常にデコードして結果を得ることができます。復号化の結果は、次のASN.1 DERエンコード文字列です。
30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 5B AC 45 51 B9 A5 51 68 28 89
51 59 1F 62 31 9B A7 15 50 CB
それを解析すると、5bac4551b9a55168288951591f62319ba71550cbが何かのSHA1ハッシュであることを示しています。 しかし、それはmanifest.jsonのSHA1ではありません（5bac...50cb！= 7335...b4d1）。
では、その復号化されたSHA1と何を比較することになっているのでしょうか。その証明書の所有者がこの特定のDERエンコードされた文字列を暗号化したことは知っていますが、それらがどのように一致するかはわかりません。 RSA/PKCS7プロセスのどの部分がここにありませんか？
ダイジェストの計算は [〜＃〜] cms [〜＃〜] （PKCS＃7の新しい名前）、セクション5.4で説明されています。つまり、署名された属性がある場合、署名されるのは属性のセットのエンコーディングです。属性の1つには、署名オブジェクトが適用されるデータファイルのハッシュが含まれているため、この署名はデータファイルまで拡張されます。この段落を参照してください：
メッセージダイジェストの計算のために、signedAttrsフィールドの個別のエンコードが実行されます。 signedAttrsのIMPLICIT [0]タグはDERエンコーディングには使用されず、EXPLICIT SET OFタグが使用されます。つまり、IMPLICIT [0]タグではなく、EXPLICIT SET OFタグのDERエンコードが、SignedAttributes値の長さおよびコンテンツオクテットとともにメッセージダイジェスト計算に含まれている必要があります。
したがって、ハッシュはSignedAttributes値の完全なエンコーディングに対して計算する必要があります。ただし、最初のバイト（0xA0である必要があります）をユニバーサルタグSET OFをエンコードするバイト（0x31、もし私が正確に覚えていれば）。