A company whose services I\'m trying to integrate uses this protocol: 1. An AES

Question

A company whose services I'm trying to integrate uses this protocol:

1. An AES key is embedded in an Android library.
2. To authenticate itself, the library sends a SHA1 hash of the key over plain HTTP.
3. The response contains an RSA public key encrypted using the same AES key.
4. A temporary AES key is generated on the client.
5. The temporary AES key and the sensitive data are encrypted with the RSA key and sent over plain HTTP.

Their excuse for not using HTTPS is that they believe they'd have to pay for a signed certificate on every mobile device they support rather than just on their server. They also believe that HTTPS adds too much network overhead for use on mobile devices. Oh, and their system is "more secure than HTTPS" because they're using longer AES keys. Did I mention this is being used for credit card processing?

I'm trying to convince them that this is utterly insane. Can anyone point me to a clear, concise explanation that's intelligible to PHBs? (Or which I could bring to the unemployment hearing if I get fired for rocking the boat?)

Explanation / Answer

Yeah, if you are describing it accurately this is completely broken, to the point of useless.

The initial AES key is compromised by being in the app, anyone with the app has access to the AES key. If this is global, then it is well and truly screwed, if it is unique to each application, there may be a small sliver of hope.

The SHA-1 is completely replayable. You mention no salt, but even if there is a salt, the attacker can replay it against a legit client as a MitM and then respond validly to appear as the client to the server.

The server would then provide the attacker with the public key, in encrypted form, which isn't particularly useful to the attacker, but it is also the public key... it is supposed to be public. Having it private offers nothing. If the client was ever compromised (or any client if the AES key is global), then the AES key is leaked by the application and the public key is also available to the attacker.

Additionally, if the AES key is compromised, the attacker can send a public key of their choice since the client has no way to verify the RSA public key.

An AES key being generated on the client is a decent enough idea, but so far, there is nothing to prevent the attacker from generating their own AES key. Additionally, they could likely provide the client with their own public key so they can also fool the client.

Why is the data being encrypted with the RSA key? What is the point of the temporary AES key then? Is it really completely unused? Encrypting long data with RSA is generally considered less secure than using symmetric encryption since it is requires more work to process and may have other security implications, the norm is just to exchange a symmetric key and use that for data exchange.

In short, the system is completely useless.

It would actually be far more useful if they simply embedded the public key of the server in the application and used that to have the client generate an AES key and exchange that for session communication. It wouldn't validate anything about the client itself, but that could be done through passwords or other tokens after the session is initialized. At that point you are pretty close to just using a self signed HTTPS though, but it could be used as a custom implementation if HTTPS isn't an option for some reason (such as not being able to add a trusted root certificate on the client devices.)

Related Questions

Navigate

• Browse (All)
• Browse A
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.