A few days ago, I threw together an implementation of authentication for AbiathRPC based on VeriMaps certificates. Today I actually tested it, and I found that it didn't work: the data to sign has to be the same length of a hash produced by the hash algorithm used by the signature formatter. (Makes sense.) I changed the server to SHA256 the GUID before sending it to the client as the challenge. After fixing a couple simple oversights, VeriMaps authentication works as intended.
I considered whether a malicious server could get a client to sign an arbitrary blob of data (e.g. the SHA512 hash for a VeriMaps-signed level set). The choice of SHA256 for this hash algorithm makes it impossible for the server to use a level set's hash as the challenge. This setup is still less than ideal, since it precludes any other VeriMaps security systems that use SHA256. Therefore, I will change the server to always produce a challenge that starts with some constant value (e.g. "RPC") and change the client to check for that before signing. Nothing I do here can defend against man-in-the-middle attacks, but that's what real TLS is for.
No comments:
Post a Comment