Should I choice RSA or AES, if I write a key into a Hardware Token for my client and I save a key in my server

Question

I provide a tool product and a hardware token for my client. And my server send some messages to command the tool regularly. The tool read the key in the hardware token and verify my message when receive it. The tool will never pass any data to me.

There is a business requirement that the tool be not allowed to send any data. I want to encrypt the messages from server to the tool, its length is less than 100 letters. Encryption efficacy is not important for me.

I'm considering RSA or AES.

AES is a safety Symmetric-key algorithm. However if the hardware token key breachs, my client can send any command to the tool.(Although it is unlikely to happen)

If I use RSA, I can generate two keys, and I see both those as private keys. I write a key into the Hardware Token for my client and I save anthor key in my server.Even though the hardware token key breachs, my client still can't send any command to the tool. My client can parse my message at most.So that using RSA is better than AES for me, is it?

---

Is this a feasible solution? :

I save a fixed hardcode RSA public key in the tool, and write a AES private key into device token for client. And I save a fixed hardcode RSA private key in my server, and save a same AES private key (the same with AES for client) in DB. When semd message from server, encrypt it by AES,then encrypt it by RSA.

So even though the AES key breach, my client still can't send any command to the tool (because RSA). My client can parse my message at most (with using RSA public key and AES private Key).

Thank you!

Answer 1

Even though the hardware token key breachs, my client still can't send any command to the tool.

Not true because an RSA public key can be derived trivially from the private key - and your client has that private key. Then the client could encrypt the commands with the public key they derived from the client key you put in your tool.

What you can do is use two sets of RSA keys:

1. The encryption set. Put the private key in your tool. Use the public key to encrypt commands sent to the tool. Use the private key in the tool to decrypt the commands. This is really just obfuscating the command - the client has access to the tool, so if they really want to they can probably figure out what the commands are.

2. A signing set. Use a second pair of RSA keys to sign the data. Keep the private key, and use it to sign the commands, then put the public key from this key pair into your tool, and use it to verify that the signed command is authentic. If the command has not been signed by your private key (that you keep private!), then it's not valid.

You'd first encrypt your command using the first RSA pair's public key, then take that result and sign it using the private key of the second RSA key pair, then send both the command and the signature to your tool, which would first use the public key of the second RSA pair to verify the encrypted command is genuine, then use the private key of the first key pair to decrypt the command.

I'm assuming all commands are small enough to be encrypted using the public key of the first RSA key pair. RSA encryption is limited to the size of the key itself* minus some bytes due to RSA padding. IIRC PKCS#1.5 (old but still the default for many implementations...) padding is 11 bytes, while OAEP padding with SHA-256 used for both the hash and the mask generation functions needs 66 bytes of padding. Thus a 2048-bit (256 byte) RSA key can encrypt up to 245 bytes of data if PKCS#1.5 padding is used, or 190 bytes of OAEP padding with SHA-256/SHA-256 is used.

Now, your client has physical access to your tool - if they really know what they're doing, they can take full control of it and make it run any command they want, and there's really nothing technical you can do about it. You just have to make it hard so it's not worth the effort (and - importantly - hard enough so they can't say "Umm, it was an accident. We didn't mean to spend four months taking apart your tool, reverse engineer it, and then extract and disassemble your code from the EEPROM we physically removed from your tool."), and put something in your license agreement(s) about clients not hacking your tools so they'd create legal problems for themselves if they hack it anyway.

* - the actual RSA encryption limit is the value of the RSA public key modulus, but the use of padding results in a smaller limit.