Post not yet marked as solved
Hi,
We have a multi-platform application that requires integrity attestation before the backend will enable supporting services (fairly common scenario).
I've read the documentation for DeviceCheck and AppAttest, as well as SafetyNet on the Android side.
The Android documentation includes lots of examples of use, including server-side (though oddly in C# and Javascript... which I don't see as being server-side languages, but... oh, well).
Anyway, maybe there's a server-side example of using an application attestation on the server when validating a client, as well as validating individual requests with assertions, but I've not been able to find it.
It seems like a relatively important bit of functionality to ensure that apps aren't being compromised, while at the same time requiring a correct implementation... Why not give a reference implementation as a starting point to make sure developers are on the right path?
Can anyone point me at an example as a Gist, etc?
Thanks.
Post not yet marked as solved
Hi,
I was looking through our MTA logs and I noticed that the MacOS client sends:
HELO smtpclient.apple
when it should be sending:
HELO my.fq.dn
or if it has no meaningful mapping to a domain name, at least:
HELO [192.168.1.19]
Per RFC-2821:
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP
server. The argument field contains the fully-qualified domain name
of the SMTP client if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system. The SMTP server identifies itself to the SMTP
client in the connection greeting reply and in the response to this
command.
This seems pretty straightforward; why is the standard not being followed?
Just double-checked: the iOS client does the same.
If they all send the same meaningless string, this makes reading logs that much harder.
Should be trivial to fix.
Thunderbird had a similar bug, but I fixed that 15 years ago.
Why diverge from the standards? SMTP is one of the easier RFC's to implement.
Thanks,
-Philip
Post not yet marked as solved
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
Post not yet marked as solved
I was reading a thread about this earlier today, and alas didn't bookmark it, or I would continue it... even if the thread is 6+ years old.
Someone was asking if GPS (and by extension, Location Services including changing timezones, etc) worked in airplane-mode.
Since then:
the FAA has relaxed rules about using mobile devices on aircraft that radiate RF energy;
new radio chips with different architectures have emerged;
etc.
While it might have been the case that shutting down the cellular PHY (transceiver) also killed the GPS receiver, that might not be the case today. Or is it a deliberate decision in iOS design that airplane-mode turns off GPS, even though GPS is a passive receiver that doesn't radiate RF, and whether the transceiver/receiver can be enabled separately or not is moot?
I'm thinking of a use-case where a citizen journalist might be photo-documenting events in his country (and wanting to attach time/location metadata to photographs as he takes them) without wanting to emit any sort of RF signature that might allow state security services to track him (i.e. using WiFi certified location services or cellular service for time or AGPS+).
Thanks
Post not yet marked as solved
Hi,
I was reading Storing Keys in the Secure Enclave and was thinking, "that's great if you're writing new code from scratch, or updating an iOS-only code base...", but how do people integrate this functionality into well-worn packages, such as Openssl?
What's the best practice for representing the Secure Enclave keystore in software? Is it closest to an HSM (hardware security module)? Or to a PKCS11 crypto-token like a smart card? Or maybe it's sufficiently unlike anything else.
We have some management scripting that uses Openssl and I'd like to be able to make it "just work" with Secure Enclave keystore, but don't see any guidance on how best to do that.
What is the developer community's collective experience and wisdom here?
Thanks,
-Philip
PhilipTP.