Openssl verify fails with iOS Secure Enclave created signature - php

Question

I am attempting to hash and sign user data on iOS (14.4), send that to my server, and have the server verify the hash and the signature with a previously uploaded public key (sent on keypair generation during user creation). It seems a number of people have run into issues with this, but all of the answers I've been able to find are very old, don't factor in using Apple's Secure Enclave, or revolve around signing and verifying on the same iOS device.
The general workflow is: User creates an account on iOS, and a random keypair is created on the device with the private key remaining in the Secure Enclave, while the public key is converted to ASN.1 format, PEM encoded and uploaded to the server. When the user later signs data, the data is JSONEncoded, hashed with sha512, and signed by their private key in the Secure Enclave. This is then packaged into a base64EncodedString payload, and sent to the server for verification. The server first verifies the hash using openssl_digest and then checks the signature using openssl_verify.
I have been unable to get the openssl_verify method to successfully verify the signature. I have also attempted using the phpseclib library (to get more insight into why the verification fails) without success. I understand phpseclib uses the openssl library if it is available, but even if this is disabled, phpseclib's internal verification fails because the resulting values after modulus do not match. Interestingly, phpseclib converts the public key to what looks like PKCS8 formatting with a large amount of padding.
It appears the public key is being parsed and loaded properly by openssl, as a proper reference is being created prior to verification. However, since the private key is opaque (residing in the Secure Enclave) I don't have a way to externally "check" how the signatures themselves are generated/encoded or if the same signature would be created outside of the iOS device. I'm wondering if I have an encoding error, or if external verification is possible with keys generated in the Secure Enclave.
iOS Public Key Upload method- I am using CryptoExportImportManager which converts the raw bytes to DER, adds the ASN.1 header, and adds the BEGIN and END key tags.
public func convertPublicKeyForExport() -> String?
{
let keyData = SecKeyCopyExternalRepresentation(publicKey!, nil)! as Data
let keyType = kSecAttrKeyTypeECSECPrimeRandom
let keySize = 256
let exportManager = CryptoExportImportManager()
let exportablePEMKey = exportManager.exportECPublicKeyToPEM(keyData, keyType: keyType as String,
keySize: keySize)
return exportablePEMKey
}
An example of what one of the public keys looks like after upload
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEf16tnH8YPjslaacdtdde4wRQs0PP
zj/nWgBC/JY5aeajHhbKAf75t6Umz6vFGBsdgM/AFMkeB4n2Qi96ePNjFg==
-----END PUBLIC KEY-----
let encoder = JSONEncoder()
guard let payloadJson = try? encoder.encode(["user_id": "\(user!.userID)", "random_id": randomID])
else
{
onCompletion(nil, NSError())
print("Failed creating data")
return
}
let hash = SHA512.hash(data: payloadJson)
guard let signature = signData(payload: payloadJson, key: (user?.userKey.privateKey)!) else
{
print("Could not sign data payload")
onCompletion(nil, NSError())
return
}
let params = Payload(
payload_hash: hash.hexString,
payload_json: payloadJson,
signatures: ["user": [
"signature": signature.base64EncodedString(),
"type": "ecdsa-sha512"
]]
)
let encoding = try? encoder.encode(params).base64EncodedString()
The sign data function is pretty close to Apple's documentation code, but I'm including it for reference
private func signData(payload: Data, key: SecKey) -> Data?
{
var error: Unmanaged<CFError>?
guard let signature = SecKeyCreateSignature(key,
SecKeyAlgorithm.ecdsaSignatureMessageX962SHA512,
payload as CFData, &error)
else
{
print("Signing payload failed with \(error)")
return nil
}
print("Created signature as \(signature)")
return signature as Data
}

Answer 1

I actually stumbled upon the solution while doing additional research and experimentation while writing this question. The problem of course had nothing to do with the keys or algorithms, and everything to do with the way Apple hashes data objects.
I had discovered a similar problem when trying to determine why my hashes were not matching on the server-side vs the ones created on the iOS device. The user JSONEncoded data is hashed and signed as a base64Encoded data object, but unknown to me (and not in any documentation I could discover) iOS decodes the Data object and hashes the raw object, and re-encodes it (since this is opaque code it's possible this is not precisely accurate, but the result is the same). Therefore when checking the hash on the user data, I had to first base64decode the object, and then perform the hash. I had assumed that Apple would sign the encoded object as is (in order to not contaminate its integrity), but in fact, when Apple creates the digest before signing, it hashes the decoded raw object and creates a signature on the raw object.
Therefore the solution was to again base64decode the object before sending it to the openssl_verify function.
Checking the hash on the server
public function is_hash_valid($payload) {
$server_payload_hash = openssl_digest(base64_decode($payload["payload_json"]), "SHA512");
$client_payload_hash = $payload["payload_hash"];
if ($client_payload_hash != $server_payload_hash) {
return false;
}
return true;
}
Verifying the signature on the server
function is_signature_valid($data, $signature, $public_key) {
$public_key = openssl_get_publickey($public_key);
$ok = openssl_verify(base64_decode($data), base64_decode($signature), $public_key, "SHA512");
if ($ok === 1) {
return true;
} else {
return false;
}
}
After discovering this, and verifying that openssl_verify and phpseclib's verify function worked correctly, I almost considered deleting the question entirely but realized that if I had discovered a question similar to this in my research, it might have saved me a good deal of time. Hopefully to anyone else that has a similar issue, this will prove helpful.