![[Home]](http://meatballwiki.org/meatball.gif)
NumberUsedOnce
MeatballWiki | RecentChanges | Random Page | Indices | CategoriesIn systems where transactions with end users can result in either sensitive changes being made or sensitive information being given out, transactions need to be secured from third party attackers. The primary method to secure a transaction is by authenticating the end user and then authorizating him or her for the given transaction. A third party that does not possess the credentials of a legitimate end user will not be able to complete the transaction, and thus the transaction is secure.
If the method of authentication occurs over a secured channel so that no one else can eavesdrop, such as presenting your bank book to a teller in person, then this level of security is usually sufficient. However, on the Internet, most transactions happen in the public, where who knows who is listening in on the communication. Exchanging credentials in the public will give those credentials away to any attacker listening in on the transaction. Therefore, the secondary method to secure a transaction is to obscure the credentials with cryptography so that the eavesdropper will not be able to copy the credentials.
Having a copy of the original credentials is not necessary, however. Consider what happens if an attacker has a copy of every message in the transaction. If she opens a new transaction with the service, what happens if she simply sent each message in the transaction again, even withing knowing what their unencrypted contents might be? For many services, she would get the same result back at the end of the transaction. This attack is called replay.
Replaying a transaction that has already occured or is not expected must fail. The simplest solution is to give each transaction a unique identifier. A replayed transaction will fail because the unique identifier has already been used. If the server keeps a list of all the ids of open transactions, attempts to manipulate the unique identifier before replaying the transaction will fail because the identifier is not in the list. That being said, if the sequence of unique identifiers is relatively predictable, an attacker can guess which identifiers are in the list of open transactions. Therefore, the unique identifiers need to be a random sequence, rather than, say, a monotonically increasing counter. In another scenario, an attacker can open a new transaction under their own credentials and then insert the identifier inside their victim's transaction. Therefore, the unique identifiers need to be associated with end user identities so they cannot be transferred.
Even giving each transaction a unique identifier does not help for transactions that are many message exchanges long, as the unique identifier would remain constant in each message. This means an attacker would have the opportunity to replay a message while the transaction is still open. Say you were transfering money to the attacker; the attacker could double his money just be resending the transfer message. Therefore, the unique identifier has to be used only for one message exchange and then discarded in favour of a new identifier. It is effectively a NumberUsedOnce and only once, aka a nonce. Once you send your money transfer command, its identifier will be invalid, so your attacker's attempt to replay the message will fail.
Therefore, for highly sensitive transactions,
- The client requests a transaction,
- The server generates a new random nonce,
- The server records the nonce and the client id in its list of open nonces,
- The server sends the nonce to the client as part of an encrypted message,
- The client makes a request identified with the nonce,
- The server verifies the nonce is in its list of open nonces,
- The server verifies the client is the owner of the nonce,
- The server completes the action,
- The server closes the nonce.
- Some systems destroy it.
- Some systems keep it for a time (DynamicValue) or forever to ensure a) no new nonce is the same as a (recent) previous nonce, b) in event of a ManInTheMiddle? replay attack, it is easier to detect which account has been compromised.
- Either, the server returns the result and closes the transaction
- Or, the server generates (and records) the next nonce and returns the result and the next nonce to the client and awaits the next message.
Good implementations put a time out on the nonces (cf. DynamicValue). Otherwise, after a while, many incomplete transactions will result in a long list of open but unused nonces. An attacker will then have a higher probability of guessing at random an available nonce. Very good implementations will record information that identifies the source of the transaction such as the IP address of the requesting client, user agent, and other such information to ensure future messages within the transaction come from the same source.
But, if your attacker can read the content of the messages because they are plaintext or your encryption has been compromised, this strategy is vulnerable. If your attacker can intercept both your incoming and outgoing messages, she may intercept the nonce provided by the service for the next message exchange and send a message with that nonce before you do.
One method to increase the strength of the encryption is to append the nonce as part of the encryption key (a salt). While nothing can help you if the attacker has already broken your encryption as the first message requesting the first nonce must be sent without the salt, using the nonce as a salt reduces the amount of cyphertext available to an attacker which will make cracking your key much harder.
Sending a nonce in plaintext is more viable if it is coupled with information that ties a transaction to its source (e.g. IP address). For instance, nonces can prevent rotating OpenProxy attackers from moving through an multi-message transaction (e.g. edit page-save page) with different IPs in order to hopefully skirt the OpenProxy detector. However, note that if an attacker knows the victim's connection information, she can spoof the victim's IP address. Presumably if they attacker is already snooping on the victim's traffic, the attacker already has this information. In practice, this is unlikely to be a major issue for you unless big money is involved.
In Austria (probably at least in Europe) banks secure their internet transactions by transaction numbers (TNs). These numbers are - of course - random sequences and they are sent in chunks of 100 to the customer by snail mail. When the customer has used the first 10 TNs from a letter, he gets the next letter containing the next 100 TNs, so he will normally not run out of transaction numbers.
The older system of using these TNs was less secure: customers just entered one of the TNs at free will. Trojans could intercept that and use the TN for a single fraud transaction.
In early 2006 the use of TNs was changed to a more secure scheme. The bank now sends the index (1..100 within the letter) of an random unused TN and the customer has to look up and enter the corresponding TN. Even if a Torjan intercepts this, it will not be able to use the TN because the bank will not ask for the same TN twice.
This is also the basis of the one-time pad. [1] Numbers are repeated, because there are only so many of them, but the overall pattern is completely unique, and never reused.
-- LionKimbro
CategoryCryptography