I'm looking at a development attestation for an app we're developing in-house, and there's a couple of undocumented PEN's being used:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1631564652467 (0x17be0d4dfb3)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN = Apple App Attestation CA 1, O = Apple Inc., ST = California
Validity
Not Before: Sep 12 20:24:12 2021 GMT
Not After : Sep 15 20:24:12 2021 GMT
Subject: CN = a203e1588ab36ae2ffc362491c2948df5d03f3ed048d0c58a59c9e085724353c, OU = AAA Certification, O = Apple Inc., ST = California
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:09:1a:ae:9f:d2:0b:89:e6:6b:ab:68:3e:70:e1:
6d:0f:b1:2f:8b:4b:bd:c9:d2:54:ec:15:2c:b4:fc:
4c:8d:fb:e1:49:0d:90:34:80:10:82:08:6c:49:58:
7e:2c:5b:90:2b:80:2d:1f:f3:e9:36:59:51:d2:3e:
1d:d2:f8:75:e3
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
1.2.840.113635.100.8.5:
0:d=0 hl=2 l= 111 cons: SEQUENCE
2:d=1 hl=2 l= 3 cons: cont [ 4 ]
4:d=2 hl=2 l= 1 prim: INTEGER :0A
7:d=1 hl=4 l= 3 cons: cont [ 1200 ]
11:d=2 hl=2 l= 1 prim: INTEGER :01
14:d=1 hl=4 l= 3 cons: cont [ 1201 ]
18:d=2 hl=2 l= 1 prim: INTEGER :00
21:d=1 hl=4 l= 3 cons: cont [ 1202 ]
25:d=2 hl=2 l= 1 prim: INTEGER :01
28:d=1 hl=4 l= 3 cons: cont [ 1203 ]
32:d=2 hl=2 l= 1 prim: INTEGER :01
35:d=1 hl=4 l= 38 cons: cont [ 1204 ]
39:d=2 hl=2 l= 36 prim: OCTET STRING :XKXEK7P8ZU.com.truepic.appattestdemo
77:d=1 hl=2 l= 6 cons: cont [ 5 ]
79:d=2 hl=2 l= 4 prim: OCTET STRING :sks
85:d=1 hl=4 l= 3 cons: cont [ 1206 ]
89:d=2 hl=2 l= 1 prim: INTEGER :05
92:d=1 hl=4 l= 3 cons: cont [ 1207 ]
96:d=2 hl=2 l= 1 prim: INTEGER :00
99:d=1 hl=4 l= 3 cons: cont [ 1209 ]
103:d=2 hl=2 l= 1 prim: INTEGER :00
106:d=1 hl=4 l= 3 cons: cont [ 1210 ]
110:d=2 hl=2 l= 1 prim: INTEGER :00
1.2.840.113635.100.8.7:
0:d=0 hl=2 l= 6 cons: SEQUENCE
2:d=1 hl=4 l= 2 cons: cont [ 1400 ]
6:d=2 hl=2 l= 0 prim: OCTET STRING
1.2.840.113635.100.8.2:
0:d=0 hl=2 l= 36 cons: SEQUENCE
2:d=1 hl=2 l= 34 cons: cont [ 1 ]
4:d=2 hl=2 l= 32 prim: OCTET STRING
0000 - 52 93 c9 c6 69 4e 74 3c-63 13 4b d0 0a 92 12 87 R...iNt<c.K.....
0010 - 36 64 cf c3 3d 8d c0 5b-3b 26 72 5a a4 5a ab 71 6d..=..[;&rZ.Z.q
Signature Algorithm: ecdsa-with-SHA256
30:65:02:31:00:d0:40:c9:18:68:10:c7:0d:2a:04:31:9a:38:
74:7a:ee:1e:a3:da:a3:58:05:0f:15:ae:86:9e:19:07:b8:d3:
67:fc:c1:3f:e4:c2:eb:1b:37:d5:b1:c3:6f:df:52:da:c0:02:
30:5b:8e:d8:67:9e:5d:59:64:68:bf:85:a8:a7:ae:e8:a8:e4:
06:f0:df:75:c5:e8:7e:0a:d4:24:64:e8:6c:c3:2d:ac:31:bf:
3f:d1:78:a7:00:ff:11:31:1b:28:08:27:5d
.2 I get. It's documented in Validating Apps That Connect to Your Server.
Some GitHub gists suggest that .7 is supposed to be an Octet String containing the iOS version number, but it's empty in our case. Unclear why.
No idea what .5 is supposed to be.
Does anyone have any insight into these last two?
Also, how does one determine the particular that's generating the attestation? Android SafetyNet attestation generates a unique hash (as the list of SHA256's in apkCertificateDigestSha256); it seems to me that we might want to further fine-tune the handling of sensitive operations based on the specifics of the version.
Lastly, the above cited documentation states, in the "Store the Public Key and Receipt" section:
Store the verified public key from credCert on your server and associate it with the user for the specific device. You use this key to check assertions later.
But iOS (and iPadOS) doesn't support multiple accounts per device. So I'm interpreting this to not refer to an associated AppleID, but rather credentials in some app-specific space defined by the app developer. Is that correct?
Thanks