App Attest

RSS for tag

Validate the integrity of your app before your server provides access to sensitive data.

Posts under App Attest tag

96 Posts

Post

Replies

Boosts

Views

Activity

Where to store App Attest key id persistently?
Dear Experts, Where is the best place to persist an App Attest key id? The docs ( https://developer.apple.com/documentation/devicecheck/establishing_your_app_s_integrity ) say “Record the identifier in persistent storage — for example, by writing it to a file”. That is what I have done, but I have encountered a problem. If a user gets a new device and restores a backup of an old device onto it, the new device will try to use the key id from the old device - which is of course wrong. One solution is to detect the error when the invalid key is used and to generate a new one. Is that the best approach? I am wondering if there is some part of the filesystem that does not survive the backup/restore process, but is otherwise persistent? It should be more persistent than a cache file. (Also looking at the docs again I now see that I am supposed to store distinct keys for each “user”. What is meant by “user” in this case?) Thanks.
1
1
1.2k
Apr ’22
DeviceCheck(iOS 11+) Vs AppAttest(iOS 14+)
We see appAttest (available iOS 14+) provides us 3 key features: if app instance is not modified, device is genuine apple device and payload is not tempered with. We also have deviceCheck Api (iOS 11+) which return 2 bits per device, as mentioned in documentation we can create different payloads for validation and different for updating the 2 bits. Apart from returning those bits in validation request, does this DeviceCheck APIs also validate 2 of the 3 above features i.e. app is not modified and the device is genuine apple device? If yes, what response from apple server to look for in successful validation of above 2 features and what response to look for in fraud cases or failure cases? Does isSupported in case of DCDevice.current hints the device is a simulator ? Can we get exhaustive list of cases where isSupported is false? Does DCDevice.current.generateToken fails only in case of modified app instance? Can we get exhaustive list of cases where above can throw error? Can modified app instance also able to generateToken?
1
0
5.5k
Mar ’22
Reusing the same key across multiple users on a device
According to documentation, the guideline is as follows - "Don’t reuse a key among multiple users on a device because this weakens security protections. In particular, it becomes hard to detect an attack that uses a single compromised device to serve multiple remote users running a compromised version of your app." This can be addressed if we keep a tally of how many users have used the same key pair? If we see a single key pair in use across say 500 users, it's clearly an instance of compromised device. Are there other security reasons why binding a key to device + user is the recommended practice?
1
0
1.4k
Mar ’22
DeviceCheck for Enterprise Account
Hi, I'm trying to validate device token generated on app which is signed by Enterprise account. I generate deviceToken on device I send the token to our backend Our backend creates JWT token The backend calls validate_device_token endpoint and receives 401 The authentication token can't be verified I've seen many implementations on the internet and I'm pretty sure that we generate the token in correct way. (eg implementation: https://github.com/marinosoftware/DeviceCheckSample) The Questions are: Is it possible to use DeviceCheck on Enterprise Account ? There is no possibility to enable DeviceCheck on Enterprise account is APNs key configuration: https://developer.apple.com/account/resources/authkeys/list. Is this configuration required ? Is there is a way to validate signature of JWT token locally ? Services such as https://jwt.io requires Public and Private keys in correct format, I didn't find a way to validate the signature signed by p8 certificate without any additional keys.
1
0
1.2k
Mar ’22
Step 5: SHA256 hash of the public key failing
Hi. I'm trying to implement App Attest on my App and I followed the guidelines from https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server but step 5 isn't waking. I got an example from https://blog.restlesslabs.com/john/ios-app-attest to implement all 9 steps using Python. Is there any example of this server-side implementation so I can double check what's wrong? PS: I saw one in Kotlin but that doesn't help me. I'm testing on an iPhone X and I can get the key identifier, the challenge and the attestation object. All steps except 5 are working (well, I had to base64 decode the identifier for step 9). Please, any help is appreciated. Regards, Cassio
1
0
1.3k
Nov ’21
Apple /v1/attestationData endpoint returning 400 request with valid receipt base64 data
Hello, I am sending valid base64 receipt data to Apple on the https://data-development.appattest.apple.com/v1/attestationData endpoint and am getting 400 bad request. I have a valid JWT that I currently use successfully for other DeviceCheck endpoints such as persistent bits. Any help debugging would be useful. Thanks
2
0
1.2k
Oct ’21
AppAttest Assertion - signature verification failing
Hello, I'm implementing AppAttest for one of our apps. Though the Attestation procedure works fine, the assertion signed by the private key on the device (via generateAssertion) can't be verified at the server with the public key saved during the attestation. Environment AppAttest entitlement: development iOS 14 Server: Nodejs The client (app) and server code specific to assertion is below. Client side code (app) if let clientData = self.prepareClientData(withChallenge: challenge) { 		// generate assertion 		let clientDataHash = Data(SHA256.hash(data: clientData)) 		DCAppAttestService.shared.generateAssertion(keyId!, clientDataHash: clientDataHash) { assertion, error in 				guard error == nil else { 						print ("ERROR: Assertion not available right now") 						return 				} 				// create assertion request 				var urlRequest = URLRequest(url: URL(string: self.assertEP)!) 				urlRequest.httpMethod = "POST" 				urlRequest.addValue("application/json", forHTTPHeaderField: "Content-Type") 				let clientDataString = clientData.base64EncodedString() 				let assertionString = assertion!.base64EncodedString() 				let assertRequest: [String: Any] = ["clientData": clientDataString, "assertion": assertionString] 				let jsonData: Data 				do { 						jsonData = try JSONSerialization.data(withJSONObject: assertRequest, options: []) 						urlRequest.httpBody = jsonData 				} catch { 						print (error) 						return 				} 				 				// send assertion request to server 				let task = URLSession.shared.dataTask(with: urlRequest) { data, response, error in 						guard error == nil else { 								// request sending failed, try again later 								print (error!) 								return 						} 						 						self.extractAssertionResponse(withData: data) 				} 				task.resume() 		} } Server side Assertion verification code function verifyAssertion(clientDataBuffer, assertionBuffer) { 		try { 				let assert = cbor.decodeAllSync(assertionBuffer)[0]; 				let authData = assert.authenticatorData; // buffer 				let signature = assert.signature; // buffer 				// compute client Data Hash 				let clientDataHash = crypto.createHash('sha256').update(clientDataBuffer).digest('base64'); 				let clientDataHashBuffer = Buffer.from(clientDataHash, 'base64'); 				// compute composite hash 				let compositeBuffer = Buffer.concat([authData, clientDataHashBuffer]); 				let nonce = crypto.createHash('sha256').update(compositeBuffer).digest('base64'); // base64 string 				let nonceBuffer = Buffer.from(nonce, 'base64'); 				// load public key 				let keyObj = crypto.createPublicKey(k_publicKeyPem); 				// verify signature 				let verifier = crypto.createVerify('sha256').update(nonceBuffer); 				let sign_verify = verifier.verify(keyObj, signature); 				console.log("sign_verify: ", sign_verify); 		} catch (e) { 				console.log(e); 		} } The verifier.verify() call always results in 'false'. I've tried 'hex' and 'base64' variations on the signature, but didn't work. I've verified that the sha256(publicKey) received at the server is equal to the keyId. let keybuf = Buffer.from(k_publicKeyRaw, 'base64'); let keySHA = crypto.createHash('sha256').update(keybuf).digest('base64'); let keyVerified = (keySHA === k_keyId); Also verified that the clientDataHash generated at the server is the same as clientDataHash generated within the app. Does crypto Verify not compatible with the generated signatures? If not, what's the suggested way to do it? I've tried all the encodings supported by crypto Verify.verify but none of those worked. crypto.getHashes(); Please help.
4
0
2.7k
Sep ’21
AppAttest attestation does not contain iOS version number
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
0
0
1.3k
Sep ’21
Multiple calls to appAttestService generateKeyWithCompletionHandler
Hello, I am currently looking into iOS App Attest and have two questions: When generateKeyWithCompletionHandler is called the closure will return the keyId as a reference to the key pair in Secure Enclave. This keyId must be kept for later use in the attestation process. Every time I call generateKeyWithCompletionHandler I will receive a new keyId. This is functionally not what you want, but it can be done and generateKeyWithCompletionHandler does not fail if it has been called previously. Will the latest returned keyId override any other keyIds created previously in the app or will all keyIds returned be valid as reference for attestation ? If all keyIds are valid will they refer to unique key pairs or point to the same key pair in the Secure Enclave? Kind regards, Steffen
1
0
636
Sep ’21
Domain Verification
We are doing domain verification and for us to verify ownership of our domain, we need to place the file at below location. https://www.domain.com/.well-known/apple-developer-merchantid-domain-association.txt However, we don't manage main domain instead we manage site with country path to it. e.g. https://www.domain.com/hk Is there a way we can do this with additional site path (/hk) like below? https://www.domain.com/hk/.well-known/apple-developer-merchantid-domain-association.txt instead of https://www.domain.com/.well-known/apple-developer-merchantid-domain-association.txt
0
0
784
Aug ’21
How AppAttest works ?
Hello, I am currently learning about how App Attest works and there are a few things I don't understand. First of all for the certificates of the attestation provided by Apple. Once verified, they attest that the associated customer has a genuine Apple device. What is meant by a genuine Apple device, a non-jailbroken device or simply a device that was produced by Apple? In addition I do not see how these certificates work, how they attest to the authenticity of the device, what they contain? Then regarding the appId, is it kept in the Secure Enclave? Because if not, a super-user could very well modify the application and then go and modify the appId to put back the original. Also, can a user use the AppAttest API without going through my application, in order to produce false certificates for example. Regarding assertion formation for requests, let's imagine that the user does not have a login. The query may possibly be stored on the device in the meantime, will the assertion have already been bound or not? Finally, since the key pair does not survive the reinstallation of the application. Is there any way to block a device that is suspected of having fraudulent activity? Thank you for your attention!
1
0
1.3k
Jul ’21
App Attest Key Generation
How is the app attestation key generated in the Secure Enclave? My client really wants to know if the attestation key is derived from the Secure Enclave's UUID, from other keys or is it just randomly generated using a CSRNG ? Any information you can provide to convince my client of the security of the key will be useful. Regards. Keldennis
1
0
1.2k
Jun ’21
Where to store App Attest key id persistently?
Dear Experts, Where is the best place to persist an App Attest key id? The docs ( https://developer.apple.com/documentation/devicecheck/establishing_your_app_s_integrity ) say “Record the identifier in persistent storage — for example, by writing it to a file”. That is what I have done, but I have encountered a problem. If a user gets a new device and restores a backup of an old device onto it, the new device will try to use the key id from the old device - which is of course wrong. One solution is to detect the error when the invalid key is used and to generate a new one. Is that the best approach? I am wondering if there is some part of the filesystem that does not survive the backup/restore process, but is otherwise persistent? It should be more persistent than a cache file. (Also looking at the docs again I now see that I am supposed to store distinct keys for each “user”. What is meant by “user” in this case?) Thanks.
Replies
1
Boosts
1
Views
1.2k
Activity
Apr ’22
DeviceCheck(iOS 11+) Vs AppAttest(iOS 14+)
We see appAttest (available iOS 14+) provides us 3 key features: if app instance is not modified, device is genuine apple device and payload is not tempered with. We also have deviceCheck Api (iOS 11+) which return 2 bits per device, as mentioned in documentation we can create different payloads for validation and different for updating the 2 bits. Apart from returning those bits in validation request, does this DeviceCheck APIs also validate 2 of the 3 above features i.e. app is not modified and the device is genuine apple device? If yes, what response from apple server to look for in successful validation of above 2 features and what response to look for in fraud cases or failure cases? Does isSupported in case of DCDevice.current hints the device is a simulator ? Can we get exhaustive list of cases where isSupported is false? Does DCDevice.current.generateToken fails only in case of modified app instance? Can we get exhaustive list of cases where above can throw error? Can modified app instance also able to generateToken?
Replies
1
Boosts
0
Views
5.5k
Activity
Mar ’22
Reusing the same key across multiple users on a device
According to documentation, the guideline is as follows - "Don’t reuse a key among multiple users on a device because this weakens security protections. In particular, it becomes hard to detect an attack that uses a single compromised device to serve multiple remote users running a compromised version of your app." This can be addressed if we keep a tally of how many users have used the same key pair? If we see a single key pair in use across say 500 users, it's clearly an instance of compromised device. Are there other security reasons why binding a key to device + user is the recommended practice?
Replies
1
Boosts
0
Views
1.4k
Activity
Mar ’22
DeviceCheck for Enterprise Account
Apple team, I need your help. Can you answer for my question in thread: https://developer.apple.com/forums/thread/701876 ? I created new thread due to I wasn't able to add tag wwdc21-10244 in thread 701876.
Replies
0
Boosts
0
Views
791
Activity
Mar ’22
DeviceCheck for Enterprise Account
Hi, I'm trying to validate device token generated on app which is signed by Enterprise account. I generate deviceToken on device I send the token to our backend Our backend creates JWT token The backend calls validate_device_token endpoint and receives 401 The authentication token can't be verified I've seen many implementations on the internet and I'm pretty sure that we generate the token in correct way. (eg implementation: https://github.com/marinosoftware/DeviceCheckSample) The Questions are: Is it possible to use DeviceCheck on Enterprise Account ? There is no possibility to enable DeviceCheck on Enterprise account is APNs key configuration: https://developer.apple.com/account/resources/authkeys/list. Is this configuration required ? Is there is a way to validate signature of JWT token locally ? Services such as https://jwt.io requires Public and Private keys in correct format, I didn't find a way to validate the signature signed by p8 certificate without any additional keys.
Replies
1
Boosts
0
Views
1.2k
Activity
Mar ’22
Unable to install App after added UDID
Hi, I have add UDID for me to install the Test Environment. However, after being installed it show this message. How to solve this ?
Replies
0
Boosts
0
Views
630
Activity
Dec ’21
Step 5: SHA256 hash of the public key failing
Hi. I'm trying to implement App Attest on my App and I followed the guidelines from https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server but step 5 isn't waking. I got an example from https://blog.restlesslabs.com/john/ios-app-attest to implement all 9 steps using Python. Is there any example of this server-side implementation so I can double check what's wrong? PS: I saw one in Kotlin but that doesn't help me. I'm testing on an iPhone X and I can get the key identifier, the challenge and the attestation object. All steps except 5 are working (well, I had to base64 decode the identifier for step 9). Please, any help is appreciated. Regards, Cassio
Replies
1
Boosts
0
Views
1.3k
Activity
Nov ’21
Cannot find App Attest Capability in Xcode
According to the App Check Firebase Documentation, it is said to add the App Attest capability to your app. However, I am not able to find any such capability in XCode. Any insights on this? Note: We have enabled capability in the provision profiles Documentation Link: https://firebase.google.com/docs/app-check/ios/app-attest-provider#install-sdk
Replies
1
Boosts
0
Views
1.7k
Activity
Oct ’21
Apple /v1/attestationData endpoint returning 400 request with valid receipt base64 data
Hello, I am sending valid base64 receipt data to Apple on the https://data-development.appattest.apple.com/v1/attestationData endpoint and am getting 400 bad request. I have a valid JWT that I currently use successfully for other DeviceCheck endpoints such as persistent bits. Any help debugging would be useful. Thanks
Replies
2
Boosts
0
Views
1.2k
Activity
Oct ’21
AppAttest Assertion - signature verification failing
Hello, I'm implementing AppAttest for one of our apps. Though the Attestation procedure works fine, the assertion signed by the private key on the device (via generateAssertion) can't be verified at the server with the public key saved during the attestation. Environment AppAttest entitlement: development iOS 14 Server: Nodejs The client (app) and server code specific to assertion is below. Client side code (app) if let clientData = self.prepareClientData(withChallenge: challenge) { 		// generate assertion 		let clientDataHash = Data(SHA256.hash(data: clientData)) 		DCAppAttestService.shared.generateAssertion(keyId!, clientDataHash: clientDataHash) { assertion, error in 				guard error == nil else { 						print ("ERROR: Assertion not available right now") 						return 				} 				// create assertion request 				var urlRequest = URLRequest(url: URL(string: self.assertEP)!) 				urlRequest.httpMethod = "POST" 				urlRequest.addValue("application/json", forHTTPHeaderField: "Content-Type") 				let clientDataString = clientData.base64EncodedString() 				let assertionString = assertion!.base64EncodedString() 				let assertRequest: [String: Any] = ["clientData": clientDataString, "assertion": assertionString] 				let jsonData: Data 				do { 						jsonData = try JSONSerialization.data(withJSONObject: assertRequest, options: []) 						urlRequest.httpBody = jsonData 				} catch { 						print (error) 						return 				} 				 				// send assertion request to server 				let task = URLSession.shared.dataTask(with: urlRequest) { data, response, error in 						guard error == nil else { 								// request sending failed, try again later 								print (error!) 								return 						} 						 						self.extractAssertionResponse(withData: data) 				} 				task.resume() 		} } Server side Assertion verification code function verifyAssertion(clientDataBuffer, assertionBuffer) { 		try { 				let assert = cbor.decodeAllSync(assertionBuffer)[0]; 				let authData = assert.authenticatorData; // buffer 				let signature = assert.signature; // buffer 				// compute client Data Hash 				let clientDataHash = crypto.createHash('sha256').update(clientDataBuffer).digest('base64'); 				let clientDataHashBuffer = Buffer.from(clientDataHash, 'base64'); 				// compute composite hash 				let compositeBuffer = Buffer.concat([authData, clientDataHashBuffer]); 				let nonce = crypto.createHash('sha256').update(compositeBuffer).digest('base64'); // base64 string 				let nonceBuffer = Buffer.from(nonce, 'base64'); 				// load public key 				let keyObj = crypto.createPublicKey(k_publicKeyPem); 				// verify signature 				let verifier = crypto.createVerify('sha256').update(nonceBuffer); 				let sign_verify = verifier.verify(keyObj, signature); 				console.log("sign_verify: ", sign_verify); 		} catch (e) { 				console.log(e); 		} } The verifier.verify() call always results in 'false'. I've tried 'hex' and 'base64' variations on the signature, but didn't work. I've verified that the sha256(publicKey) received at the server is equal to the keyId. let keybuf = Buffer.from(k_publicKeyRaw, 'base64'); let keySHA = crypto.createHash('sha256').update(keybuf).digest('base64'); let keyVerified = (keySHA === k_keyId); Also verified that the clientDataHash generated at the server is the same as clientDataHash generated within the app. Does crypto Verify not compatible with the generated signatures? If not, what's the suggested way to do it? I've tried all the encodings supported by crypto Verify.verify but none of those worked. crypto.getHashes(); Please help.
Replies
4
Boosts
0
Views
2.7k
Activity
Sep ’21
AppAttest attestation does not contain iOS version number
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
Replies
0
Boosts
0
Views
1.3k
Activity
Sep ’21
Multiple calls to appAttestService generateKeyWithCompletionHandler
Hello, I am currently looking into iOS App Attest and have two questions: When generateKeyWithCompletionHandler is called the closure will return the keyId as a reference to the key pair in Secure Enclave. This keyId must be kept for later use in the attestation process. Every time I call generateKeyWithCompletionHandler I will receive a new keyId. This is functionally not what you want, but it can be done and generateKeyWithCompletionHandler does not fail if it has been called previously. Will the latest returned keyId override any other keyIds created previously in the app or will all keyIds returned be valid as reference for attestation ? If all keyIds are valid will they refer to unique key pairs or point to the same key pair in the Secure Enclave? Kind regards, Steffen
Replies
1
Boosts
0
Views
636
Activity
Sep ’21
Domain Verification
We are doing domain verification and for us to verify ownership of our domain, we need to place the file at below location. https://www.domain.com/.well-known/apple-developer-merchantid-domain-association.txt However, we don't manage main domain instead we manage site with country path to it. e.g. https://www.domain.com/hk Is there a way we can do this with additional site path (/hk) like below? https://www.domain.com/hk/.well-known/apple-developer-merchantid-domain-association.txt instead of https://www.domain.com/.well-known/apple-developer-merchantid-domain-association.txt
Replies
0
Boosts
0
Views
784
Activity
Aug ’21
iOS 14 app attest supported devices
Documentation for app attestation in iOS 14 says "Because not all device types support the App Attest service, check for support before using the service." Does anyone know which device types are supported and which are not? Can't find that information anywhere.
Replies
2
Boosts
0
Views
1.7k
Activity
Jul ’21
How AppAttest works ?
Hello, I am currently learning about how App Attest works and there are a few things I don't understand. First of all for the certificates of the attestation provided by Apple. Once verified, they attest that the associated customer has a genuine Apple device. What is meant by a genuine Apple device, a non-jailbroken device or simply a device that was produced by Apple? In addition I do not see how these certificates work, how they attest to the authenticity of the device, what they contain? Then regarding the appId, is it kept in the Secure Enclave? Because if not, a super-user could very well modify the application and then go and modify the appId to put back the original. Also, can a user use the AppAttest API without going through my application, in order to produce false certificates for example. Regarding assertion formation for requests, let's imagine that the user does not have a login. The query may possibly be stored on the device in the meantime, will the assertion have already been bound or not? Finally, since the key pair does not survive the reinstallation of the application. Is there any way to block a device that is suspected of having fraudulent activity? Thank you for your attention!
Replies
1
Boosts
0
Views
1.3k
Activity
Jul ’21
App Attest Key Generation
How is the app attestation key generated in the Secure Enclave? My client really wants to know if the attestation key is derived from the Secure Enclave's UUID, from other keys or is it just randomly generated using a CSRNG ? Any information you can provide to convince my client of the security of the key will be useful. Regards. Keldennis
Replies
1
Boosts
0
Views
1.2k
Activity
Jun ’21