1
$\begingroup$

I'm curious about the security of RSA signing with the same public private key pair when the same message is sent multiple times. It's my understanding that once you generate the hash of the message you wish to send, that you then sign this message with your RSA private key, then transfer both this signed hash and the original message. The receiver then uses the original message to generate their own hash and compare against the result of decrypting the signed hash with the server's public key. Now that you know my understanding of the process on to the question.

Scenario: A client connects to a server and retrieves a command as well as a signed hash of this command. The server's public key is hard coded into the client. Only this server should be able to issue commands, commands will be reused

1) Is it possible for an attacker to simply log the hash of a command and then replay this hash on a server of their own thus defeating signing?

2) Assuming question one is correct how can this be prevented, I can't see a random index, being added on the end of the command, working because the server must send the original message thus exposing the "secret index" that was intended to change the hash each time.

I understand how RSA is secure when data is only sent once, but when it's sent multiple times how is it/can it be made secure? I'm looking for a possible solution. Thanks for reading.

Improve this question
$\endgroup$

2 Answers 2

Reset to default
1
$\begingroup$

You can use time as a nonce. Add a timestamp to the message before signing it.

Send the unsigned timestamp also to the receiver so that the receiver can verify the signature. Add a rule that timestamp cannot be +/- 'X' delta as compared to the current time. This rule will be verified by receiver before checking the validity of the signature. This will prevent a replay attack.

Improve this answer
$\endgroup$
2
  • $\begingroup$ That makes alot of sense and solves my question.im curious if this is the standard approach. And are there other possible solutions? $\endgroup$
    – Stephen Eckels
    Jan 17, 2015 at 3:52
  • $\begingroup$ Warning: also dangerous in situations where commands are completed quickly; i.e. within a millisecond or so. Computer clocks often don't have more precision. $\endgroup$
    – Maarten Bodewes ♦
    Jan 17, 2015 at 12:03
4
$\begingroup$

Timestamps, as mentioned by user93353, are one possible answer. The drawback is that they require synchronized clocks, which can't always be assumed.

Another possible approach to prove liveness (that is, that this isn't a replay) is for the receiver to select a random value (a "nonce"), send that to the server, and have the server sign the command concatenated with the nonce. This also foils a replay; replays cannot work unless the receiver repeats the nonce.

Improve this answer
$\endgroup$
7
  • 1
    $\begingroup$ "receiver repeats the nonce" $\: \mapsto \:$ "nonce is predicted" $\;\;\;\;$ $\endgroup$
    – user991
    Jan 17, 2015 at 6:36
  • $\begingroup$ @RickyDemer I think those are separate issues. If a large enough, cryptographically secure, random nonce is used then neither should be a problem though. $\endgroup$
    – Maarten Bodewes ♦
    Jan 17, 2015 at 12:00
  • $\begingroup$ @RickyDemer: in this instance, a predictable (or even an attacker-chosen nonce, as long as he can't choose a previously seen nonce) is a problem; to get a command to be accepted, he would need to create a signature that includes a nonce that wasn't seen before; making the nonce predictable doesn't make generating such a signature any easier. $\endgroup$
    – poncho
    Jan 17, 2015 at 14:14
  • $\begingroup$ Although this would be another possible solution, it goes against the "Server Sends Commands Only" architecture. If the server is ment ONLY to server the client should have to send nothing, and should be able to read the server like a book. $\endgroup$
    – Stephen Eckels
    Jan 17, 2015 at 14:43
  • $\begingroup$ @user2330143: yes, if the architecture forbids any client to server communications. Typically in a network architecture, that sort of this is allowed; I don't know about this specific case. $\endgroup$
    – poncho
    Jan 17, 2015 at 15:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.