Integrity, Authentication and Non-Repudiation Why you need these in your transmission security stuffs
"Why the hell hasn't Alice arrived yet?" - shouted by general Bob when he is surrounded by the enemies in the Great Hobbits War II. Bob and Alice are the two commanders of this important campaign. Two days ago, he sent a letter to inform Alice that they must unite in this place to make a combat contract. And later he received a letter supposed to be from Alice, which replied that she consensed.
The enemies, led by Frodo, did it all. They intercepted the letter from Bob and made a fake one. The content had been modified that Alice must stand still. This fake information is sent to Alice then. She believed it and sent back a consensus reply.
As we can see, since the letter itself is secureless and has no identity. Whether Alice believed or not, she will not move to the place of appointment. These things led to such a disaster for Bob.
-----------------------------------
In network computing, we can consider the letter as your account login information on a commercial website. The network packet interception, called capture or sniffer, is unavoidable and can be easily done by tools like Wireshark or Fiddler. But at least, we can do something to guarantee our information sent to a node in a network is valid, and vice versa.
As I mentioned in the title, there are three of the common properties which are essential for your secure stuff when communicating through the network.In some cases, these properties are not necessary, but in others, the lack of one of these can lead to disaster. So don't be like Bob, we can choose our path.
For example, there is 3 field in the message when you transfer money to another bank account. The message is sent from your company's server to the bank server:
From the sender perspective, in details, we firstly make a date combined value from the message, such as a String, which can be done by appending 3 fields together in order (in the contract):
So from $100-Foo-Bar, now we have the hash value:
Once the bank server receives the messages, it first checks the hash value by following the rules in the contract: appending 3 fields together to make a server hash format and hash them to data called "serverHash", then compare serverHash value to the value of field "hash" in the message.
If the are the same, the bank server is sure that 3 and only 3 fields in the hash format are things of integrity. At least the message has not been accidentally modified, which value of the 3 fields cannot be modified by physical infrastructure.
The value of "extraInfo" can be modified on the network without changing "hash". So the server may receive Hail Tomato but still accepts the message. Because in the contract, we don't put it in the hash format, and the bank server is not interesting in this value.
And then, there comes a very bad guy, who uses the tool to capture our message on the network. He understands the message and wants to change the toAccount value to "BadGuyAccount", with the amount changed to "$9999". He notices the hash and recognizes it is the SHA-256 algorithm. So he try making the hash format by using the Trial And Error Method. Finally, he knows the order of the appending fields to build the format. So he changes the message to:
So using a hash only gives Integrity.
If comes such a situation like a strange valid message was processed, the sender:
- Cannot repudiate, because they are the only one who keeps the private key, which creates the signature of the message.
- If the message is really not from the sender in contract, everything is their fault, because the private key somehow was leaked, and they are the keeper.
So we just did half of the work, because the sender can say that: "It wasn't me because my privateKey was stolen!". That is actually a repudiation sentence. So how can we achieve such a property like that? I'm afraid we do not yet have an answer because non-repudiation is a legal concept. I found a very interesting answer here for this.
This is how we try to achieve non-repudiation. Moreover, as you notice, this also achieves both integrity and authentication.
The enemies, led by Frodo, did it all. They intercepted the letter from Bob and made a fake one. The content had been modified that Alice must stand still. This fake information is sent to Alice then. She believed it and sent back a consensus reply.
As we can see, since the letter itself is secureless and has no identity. Whether Alice believed or not, she will not move to the place of appointment. These things led to such a disaster for Bob.
-----------------------------------
In network computing, we can consider the letter as your account login information on a commercial website. The network packet interception, called capture or sniffer, is unavoidable and can be easily done by tools like Wireshark or Fiddler. But at least, we can do something to guarantee our information sent to a node in a network is valid, and vice versa.
As I mentioned in the title, there are three of the common properties which are essential for your secure stuff when communicating through the network.In some cases, these properties are not necessary, but in others, the lack of one of these can lead to disaster. So don't be like Bob, we can choose our path.
For example, there is 3 field in the message when you transfer money to another bank account. The message is sent from your company's server to the bank server:
- fromAccount: Foo - toAccount: Bar - amount: $100 - extraInfo: Hail Potato
We will go through one by one of the properties.
Integrity
The received message must be the same as the sent one, no more, no less. The recipient can be confident that the message has not been accidentally modified on the network.
How can we achieve this property?
The most widely used way is hashing the message (without appending key).
To achieve integrity, we firstly make a contract in communication between the sender (the company server) and the recipient (bank server). These rules can be listed:
How can we achieve this property?
The most widely used way is hashing the message (without appending key).
To achieve integrity, we firstly make a contract in communication between the sender (the company server) and the recipient (bank server). These rules can be listed:
- The essential data: fromAccount, toAccount, amount - The Hashing algorithm: we choose SHA-256 in Hexa. - The ordering of data (in message) for hashing (called hash format): <amount>-<fromAccount>-<toAccount>
From the sender perspective, in details, we firstly make a date combined value from the message, such as a String, which can be done by appending 3 fields together in order (in the contract):
Foo-Bar-$100Then we hash these String using a specific hash algorithm. In this case, we use SHA-256 (as in the contract). There's an online tool, you can check it out at https://xorbin.com/tools/sha256-hash-calculator
So from $100-Foo-Bar, now we have the hash value:
746cb1a423121fa1a795a46c450a1406df06453497040343a8538ec78f987208Now we (the company server) add a new field to the message itself, called "hash", the message becomes:
- fromAccount: Foo - toAccount: Bar - amount: $100 - extraInfo: Hail Potato - hash: ede29ea6925b03e011ec38a2e35fc0476ec0cdd0697b0358cfda9772d293811fNow we send it to the network.
Once the bank server receives the messages, it first checks the hash value by following the rules in the contract: appending 3 fields together to make a server hash format and hash them to data called "serverHash", then compare serverHash value to the value of field "hash" in the message.
If the are the same, the bank server is sure that 3 and only 3 fields in the hash format are things of integrity. At least the message has not been accidentally modified, which value of the 3 fields cannot be modified by physical infrastructure.
The value of "extraInfo" can be modified on the network without changing "hash". So the server may receive Hail Tomato but still accepts the message. Because in the contract, we don't put it in the hash format, and the bank server is not interesting in this value.
And then, there comes a very bad guy, who uses the tool to capture our message on the network. He understands the message and wants to change the toAccount value to "BadGuyAccount", with the amount changed to "$9999". He notices the hash and recognizes it is the SHA-256 algorithm. So he try making the hash format by using the Trial And Error Method. Finally, he knows the order of the appending fields to build the format. So he changes the message to:
- fromAccount: Foo - toAccount: BadGuyAccount - amount: $999999 - extraInfo: Hail Potato - hash: 32ead3302247048d08c20fe025aaad6e70abfb540faf814e10fc3094282bbc7dThe bank server receives the fake message but has no doubt because the hash is valid, then process the transaction. The bad guy wins, which is not a happy ending.
So using a hash only gives Integrity.
Authentication
The received message must be sent from the sender in contract, not anyone else, include that bad guy.
To achieve this, we will add several things to the contract:
- This is our common key, our secret, don't lose it or tell anyone about it: verysecretkey.
Back to the example, now we use the MAC (message authentication code) to protect our message. We still using a hash but with the secret key in the contract. Now the hash format becomes:
The bad guy cannot use the Trial And Error Method (or he thinks he would success) to guess the order of the format data, because he doesn't know a thing about the key in the contract.
So using MAC by using a hash (or sometimes using HMAC) with a key embedded in gives us the authentication.
But one day, the bank server receives a valid message and process it. But your company then complains that they did not send any messages like that. The secret key is kept on two sides, the recipient and the sender. So this situation happens when the sender repudiates the sending message action because perhaps the recipient (or another party) somehow itself sends the message.
<amount>-<fromAccount>-<toAccount>-verysecretkey
The bad guy cannot use the Trial And Error Method (or he thinks he would success) to guess the order of the format data, because he doesn't know a thing about the key in the contract.
So using MAC by using a hash (or sometimes using HMAC) with a key embedded in gives us the authentication.
But one day, the bank server receives a valid message and process it. But your company then complains that they did not send any messages like that. The secret key is kept on two sides, the recipient and the sender. So this situation happens when the sender repudiates the sending message action because perhaps the recipient (or another party) somehow itself sends the message.
Non-Repudiation
The secret key in the example above is called the symmetric key, which the two keys are the same in each side. The asymmetric keys in pair, in contrast, are different in each side. There are two types:
- private key: Kept in the sender side (your company), only the sender has it.
- public key: Kept in the recipient side (the bank server).
- private key: Kept in the sender side (your company), only the sender has it.
- public key: Kept in the recipient side (the bank server).
These keys, of course, will replace the secret key in the contract. The hash we use in the above examples become a Signature, which is only the holder of the private key can create, and normally anyone knowing the public key can verify it. Using the RSA algorithm is a common way to achieve this, there is a tool for it too:https://www.devglan.com/online-tools/rsa-encryption-decryption.
So now the sender has:
So now the sender has:
- privateKey (generated from the tool): MIIBVAIBADANBgkqhkiG9w0BAQEFAASCAT4wggE6AgEAAkEAteJTwklccGL6LVCs1+9PrpmoOYg6IKdXYbKx24one3i4IJHztTDIBJtjsgYXz+eXANdDN90b2SN5YNZyh5GsywIDAQABAkB+aWAHf49UuSXhytlmdvgthLQL0Gd9/HBaAaVlzV5ljDGU1n+mMRvz+KcVVHvc6D/lA1IycBXNSsplo0kgRFHpAiEA+HkFXT1cKxXcv3O4ciBLVuYXuaMrYTkhy2cTkQeNaQ0CIQC7ZORHZcSmhqoIE8VqSFj57XyNomrgvWuEgamS6ePHNwIgZ4W8l2leQlE8hMPJADu2SAFbtytlgn9UNjO+8jjsUO0CIEYC8rquDeN9amcsI9SKhRuTG7a62J1wh4vw+Y7W7W/PAiEA8IY30J8sV+Cub+yfkUa4ucEEJSFiKrtEMUFs/gh2eEE= - data Format: Foo-Bar-$100 - Using RSA, we have the signature as: qlwUqXIyZh+dgU50tr7FRsU2Q81BY/tUZgLi8ZABahIjAbkFGuUHpW8FJq5MyyDe2Izaz6Pd1uBVAiiLyuY1Og==
The receiver has:
- publicKey (generated with privateKey in pair): MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBALXiU8JJXHBi+i1QrNfvT66ZqDmIOiCnV2GysduKJ3t4uCCR87UwyASbY7IGF8/nlwDXQzfdG9kjeWDWcoeRrMsCAwEAAQ== - Message raw data. - Signature: qlwUqXIyZh+dgU50tr7FRsU2Q81BY/tUZgLi8ZABahIjAbkFGuUHpW8FJq5MyyDe2Izaz6Pd1uBVAiiLyuY1Og== - Now receiverdecrypts the signature (using the public key) to get data format and compare to the raw data in the message.
If comes such a situation like a strange valid message was processed, the sender:
- Cannot repudiate, because they are the only one who keeps the private key, which creates the signature of the message.
- If the message is really not from the sender in contract, everything is their fault, because the private key somehow was leaked, and they are the keeper.
So we just did half of the work, because the sender can say that: "It wasn't me because my privateKey was stolen!". That is actually a repudiation sentence. So how can we achieve such a property like that? I'm afraid we do not yet have an answer because non-repudiation is a legal concept. I found a very interesting answer here for this.
This is how we try to achieve non-repudiation. Moreover, as you notice, this also achieves both integrity and authentication.
Conclusion
As we get through some simple examples which show how we can achieve the common properties using the available algorithms.
For more reading, the SSL/TLS protocol in the Application Layer in our TCP/IP model also guarantees for us the integrity and confidentiality which authentication is a part of. The TLS tries to achieve the non-repudiation by using the CA (Certification Authority), which I'll go to deep dive in the next blogs.
Thank you!
Pearly
For more reading, the SSL/TLS protocol in the Application Layer in our TCP/IP model also guarantees for us the integrity and confidentiality which authentication is a part of. The TLS tries to achieve the non-repudiation by using the CA (Certification Authority), which I'll go to deep dive in the next blogs.
Thank you!
Pearly
Comments
Post a Comment