Thinking Security: I’d Like to Return This, Please
This post is about a confusing topic in security – what’s called “non-repudiation.”
Most normal dictionaries define this as an authentication issue – for example, can I claim that someone did something on my behalf (for example, sign for something)? But in security terms, non-repudiation is a more complicated issue. A security definition of non-repudiation (from whatis.com and http://searchsecurity.techtarget.com/definition/nonrepudiation) is:
“Non-repudiation is the assurance that someone cannot deny something. Typically, non-repudiation refers to the ability to ensure that a party to a contract or communication cannot deny the authenticity of their signature on a document or the sending of a message that they originated.”
But why is this a key security concept? You can see that this definition does talk about authentication, but it also talks about sending of a message. That’s the key (no cryptographic pun intended) to non-repudiation – it’s really about validating something – someone’s identity, sending of a message, or a complete transaction. It is a key security concept because it deals with the overall security of the system and its many pieces – the authentication, the integrity of the data, and the auditing/logging subsystem that should be in place. We have to ensure that everything in the system is secure and can’t be compromised or used against us (for example, trying the transaction again, which is called a “replay attack” in security lingo).
The example that I always use to explain non-repudiation in one context is buying an item from a store. Think of it this way – you want to make sure that the store only charges you once (since you only have one item and they can’t charge you on another day or for more items because you can prove you only bought one). The same for them as well. In the case where you want to return the item, you get credited for your purchase and the store gets its item back. Also, you can’t make money from the store by returning more items than you’ve purchased. If you try to return more than you bought, the store can prove that you’ve already returned it. (You also want to make sure that someone can’t use your receipt to attack your identity, but that’s identity theft, rather than non-repudiation.)
From this example, we can see that the integrity of the transaction is at the core of this security principle. It is truly about “thinking security” because there are so many pieces involved. We have to think how we validate each identity in the transaction. The store validates your identity when you pay for the item – either by a credit/debit card or by the additional phone number that you add to the transaction if you pay cash. This information is included in the receipt with their logo on it and the bar code which contains all of the information. When you try to return an item, they scan that barcode for validation that it exists in their system, since it was entered into their system when you bought the item. We have to think about data integrity – is the receipt a valid receipt? That receipt that you hold is your proof of purchase, so the store has to acknowledge that you bought the item. It gives you non-repudiation. (The store also has to consider if the item been tampered with or used so that it’s not returnable, but this isn’t part of non-repudiation.)
It’s obvious that there is a lot of security here. Now take a banking transaction – transferring money between two participating banks. Each side must be validated so that their identity is valid. The transaction must be signed so that it doesn’t change from sender to receiver (e.g., changed from one thousand dollars to one million dollars). Each banking system maintains an audit trail that securely records the transaction so that neither side can claim that it didn’t happen. And each side has sequencing information so that if the transaction is tried again, it is flagged as a duplicate.
Wow, that’s a lot of security. The key to this concept is the auditing (some call this logging). The auditing subsystem must be trustable and unchangeable. Once a record is written into the audit record, it may not be deleted, discarded, changed, or overwritten. Furthermore, the time of each transaction is recorded securely.
The trusted auditing subsystem is one of the key features of the ClearPath operating systems. It provides all of the underlying features that make it the core of any trustable system. On the ClearPath MCP, all system logs are of a special file type (LOG) which designates that only the operating system can write to the file and that no other applications can open the file for writing. On the ClearPath OS 2200, system logs are protected while they are assigned exclusively to the Exec. After a log file has been freed by the Exec it is protected by other means, including write keys under fundamental security and access control records and clearance levels in higher security levels. These mechanisms guarantee that both of these environments can be trusted for the highest value transactions.
That’s why the ClearPath Forward operating systems are all about “thinking security”. The designers, architects, and implementers are all thinking about security so that it’s built into the system, not added on to by the clients. It’s just naturally there and “baked in” rather than “bolted on”.