• RSS
  • Twitter
  • FaceBook

Security Forums

Log in

FAQ | Search | Usergroups | Profile | Register | RSS | Posting Guidelines | Recent Posts

Secure transmission vulnerability and intrusion detection

Users browsing this topic:0 Security Fans, 0 Stealth Security Fans
Registered Security Fans: None
Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Cryptographic Theory and Cryptanalysis - Internal and Transmission Security

View previous topic :: View next topic  
Author Message
Searcherx
Just Arrived
Just Arrived


Joined: 09 Jun 2007
Posts: 0


Offline

PostPosted: Sun Jun 10, 2007 12:22 am    Post subject: Secure transmission vulnerability and intrusion detection Reply with quote

Hello everyone,

not sure if this is the right place to ask this question, but I hope someone will point me to the right direction.

I have a package which is effectively an update for a client's server sent from a central update server.
The connection between the servers is based on 128bit SSL, but also could be a secure tunnel using an RSA key pair.
The package is again encrypted with an RSA algorithm and signed. It should also include a hash checking in case the file is corrupted for some reason.

Now the questions:
1. Where to put the hash (MD5 or SHA?) to have the fastest (and most reliable) way of determining if the file is correct - outside the encrypted container or inside? Or both? Does it affect the package/security anyhow?
2. Where and how can the package or communication be attacked?
3. What parts of the transmission or package can be rewritten (injected)? Hash if it's on the outside? Signature? Encrypted file itself?
4. Even if the attacker can't succeed, he can probably corrupt the file, is there a way how to find out if the file became corrupted before encryption or it happened due to an attack?
5. It's only a one way communication, so the attacker should not be able to even connect to the central update server, but let's say he can compromise the client's server - therefore get the update file. Is there a way for him to replicate the file with his own malicious code and somehow faking the central server connection to a different client, fool him and send him the new modified update?

I hope I explained myself clearly enough

Thanks for all your help and insight
-src-
Back to top
View user's profile Send private message
Elderan
Just Arrived
Just Arrived


Joined: 08 Jun 2007
Posts: 0


Offline

PostPosted: Sun Jun 10, 2007 2:01 pm    Post subject: Re: Secure transmission vulnerability and intrusion detectio Reply with quote

Hello,
Searcherx wrote:
Hello everyone,
1. Where to put the hash (MD5 or SHA?) to have the fastest (and most reliable) way of determining if the file is correct - outside the encrypted container or inside? Or both? Does it affect the package/security anyhow?

You have to build the Hash/MAC of the plaintext, but this is hopefully clear.
There is no real security reason to store the MAC inside or outside of the container.
The only reason is speed, when you put the MAC outside of the container, then you have 128 (160, 256...) bit less for encryption and decryption.
But when the cointainer is realy big, e.g. 1 MB or more, then 16 (20... ) bytes don't care anymore.

Attention: When you just send small data packages (e.g. 5 bytes) then you should encrypt the MAC, because when an attacker gets the MAC of e.g. 5 bytes, he can with brute force recalculate the 5 bytes, but when the packages are greater than ~16 bytes, you can also store it outside


Quote:
2. Where and how can the package or communication be attacked?

The highst risk is a Man in the Middle Attack. But with signed certificates (and verification of these) you can expect this risk.
An other risk is the reinjection of old communication, so the server and the client should send a random value, and these random values are also used for the calculation of the session key.

Quote:
3. What parts of the transmission or package can be rewritten (injected)? Hash if it's on the outside? Signature? Encrypted file itself?

When you use random values at the handshake, at the beginning of the communication, then it's realy hard to inject old communications. To avoid injected packages during an activ communication, you can insert a sequence number into the data packages, and the server/client only accepts data packages with a newer number (you increments the number always by 1).
But this sequence number must be a secret, which only the server and client know it.

Quote:
4. Even if the attacker can't succeed, he can probably corrupt the file, is there a way how to find out if the file became corrupted before encryption or it happened due to an attack?

There is real/good way. Normaly you have to build the MAC of the plaintext, a MAC of the ciphertext won't work.
But when you use a symmetric algorithmen (recommended, use RSA, Diffie-Hellman e.g. only for the keyexchange), then the encryption is realy fast.

An other to check if the file became corrupted without encryption it before is to use a MAC of the ciphertext, but this MAC has to be key-based (e.g. Hash(SecrectKey || Ciphertext)).
But a MAC of the plaintext would be better.


Quote:
5. It's only a one way communication, so the attacker should not be able to even connect to the central update server, but let's say he can compromise the client's server - therefore get the update file. Is there a way for him to replicate the file with his own malicious code and somehow faking the central server connection to a different client, fool him and send him the new modified update?

The update server has to sign the update packages and each client has to verify this signatur.
An attacker cannot insert his malicious code into these update packages, because then he has to update the signatur of the file.
When he don't have the signing key (private key) of the server, he cannot build a valid signatur, e.g. he finds a collision of the hash-function for the update-file and his file which contains the malicious code.
So you should use for the signatur SHA1 or SHA256.


Here an article of exploiting MD5:
Exploiting MD5 collisions (in C#)

But it wouldn't work for a given update file with an given signatur, but it is better when you use SHA1 oder SHA256 for the signatur.




I hope I could help you.

PS: Understand how SSL/TSL works, and you can use parts from it for your protocol.
Back to top
View user's profile Send private message
Searcherx
Just Arrived
Just Arrived


Joined: 09 Jun 2007
Posts: 0


Offline

PostPosted: Mon Jun 11, 2007 1:25 am    Post subject: Reply with quote

Hi Elderan,

thanks for your quick and helpful response!

Quote:
You have to build the Hash/MAC of the plaintext, but this is hopefully clear.
There is no real security reason to store the MAC inside or outside of the container.
The only reason is speed, when you put the MAC outside of the container, then you have 128 (160, 256...) bit less for encryption and decryption.
But when the cointainer is realy big, e.g. 1 MB or more, then 16 (20... ) bytes don't care anymore.
The container is 5-10 MB, so I guess that rules out brute-froce attack on hash. Therefore I should probably conclude that speed is not the main issue here, but security is.
What is not entirely clear for me is the difference between HMAC and UMAC, although it seems H uses a predefined underlying hash function (which as you said should be at least SHA-256 to avoid collision attacks) while U is entirely random when choosing the hash function.. Or could you please elaborate a bit on which one is the best or why is one better than the other?
Quote:
The highst risk is a Man in the Middle Attack. But with signed certificates (and verification of these) you can expect this risk.
An other risk is the reinjection of old communication, so the server and the client should send a random value, and these random values are also used for the calculation of the session key.
So the server sends the the certificate which is recognized by the client as the only acceptable cert and connection is accepted, client sends it's public key which is checked on the server if it belongs to that particular client and finally the server encrypts the message using this public key and sends it to the client.
My next question is, this public key was used to encrypt the communication, but not the message, so effectively I need one more pair to create an encrypted container with the plain message inside, correct? I guess there is a better/simpler way to ensure that the communication is secure and use the public key to encrypt the message. But as I said, security is more important than speed, so which protocol/cipher is the best to use?
Quote:
When you use random values at the handshake, at the beginning of the communication, then it's realy hard to inject old communications. To avoid injected packages during an activ communication, you can insert a sequence number into the data packages, and the server/client only accepts data packages with a newer number (you increments the number always by 1).
This would stop any injection unless someone gets hold of that sequence number which could be a combination of client's id and the sequence itself. But is it really necessary if the communication is closed once the file is received and the next one requires authentification again? Or the attacker could actually resend the same handshake and gain communication channel the client?
Quote:
An other to check if the file became corrupted without encryption it before is to use a MAC of the ciphertext, but this MAC has to be key-based (e.g. Hash(SecrectKey || Ciphertext)).
But a MAC of the plaintext would be better.
Sorry, I am a bit confused here, remember I want not only to make sure my plaintext is correct, but I also want to detect if an attacker tried to modify the encrypted container as he cannot get inside to corrupt the plaintext, so he can corrupt only the container and/or the signature.
Quote:
The update server has to sign the update packages and each client has to verify this signatur.
An attacker cannot insert his malicious code into these update packages, because then he has to update the signatur of the file.
When he don't have the signing key (private key) of the server, he cannot build a valid signatur, e.g. he finds a collision of the hash-function for the update-file and his file which contains the malicious code.
So you should use for the signatur SHA1 or SHA256.

So if he is unable to create a collided package using an existing signature, there is no way for him (without the server's private key) to trick the client into accepting the package?

I have few more questions that popped in mind:
1. What is the advantage/practical use for a combination of 2 key pairs (A public + B private and vice versa), only speed?
2. If an attacker has constant flow of encrypted and signed messages and he can decrypt those messages because he has access to the private key, can he break the signature algorithm and sign a message himself (chosen-plaintext attack)?

Thanks for all your help
Back to top
View user's profile Send private message
Elderan
Just Arrived
Just Arrived


Joined: 08 Jun 2007
Posts: 0


Offline

PostPosted: Mon Jun 11, 2007 1:18 pm    Post subject: Reply with quote

Hi,
I would use a HMAC, maybe with a secret and random key. The problem of an UMAC is that you need different, collision resistent hashfunctions and the implementation of a UMAC is more complex, because Client and Server have to know, which hash function is used.

Quote:
finally the server encrypts the message using this public key and sends it to the client.

Asymmetric encryption is realy slow, use instead a handshake for generating a session key for a symmetric chiffre.

Possible is:
Server sends his cert. to the client, client verify the signatur.
Client sends his cert. to the server, server verify the signatur.

Then both using Diffie Hellman key exchange, this means, each party generates a secret value and then calculate the key exchange data.
Means, g and p can be static values (this doesn't influence the security of Diffie Hellman, there are some recommened values for g and p), then the server and the client choose a random value x and calculate: A = g^x mod p (x can be a 160-bit random value)

Then the server encrypts A (the key exchange data) with the public RSA key from the client certificate and sends it to the client. (or maybe he signs it just with the public key from the client)

The client makes the same, calulate A, encrypts (or signing) it with the RSA public key from server certificate and sends it to the server.

Then server and client decrypt the data, generates K = A^x mod p, and both parties has the same, secret, session key K.
Diffie Hellman provides perfect forward secrecy, means, if an attacker gets the private key from the client or from the server, he cannot encrypt any captured message. For this he need the secret and random value x (from one of the parties), and after each Diffie Hellman key exchange you can/should delete the secret value x.

The secret value K can then be used for a symmetric algorithm, e.g. you can build the SHA256 hash of the value K (because K can have 128 bytes or more) and use this hash e.g. for AES256.
With AES256 you encrypts your update file and all further communication.


Quote:
But is it really necessary if the communication is closed once the file is received and the next one requires authentification again?

No, a sequence number isn't necessary when the comm. closed.

Diffie Hellman use a random value, and each Diffie Hellman key exchange provides a new session key.
When an attacker tries to inject an old communication, he connects to the server, but now, the server uses a different x-value, and therefore the session key for this communication is completly different.
When an attacker injects an old message, the server decrypts it with a different session key and the only what he gets is trash (with an invalid MAC).

Quote:
Or the attacker could actually resend the same handshake and gain communication channel the client?

Diffie-Hellman key exchange provides perfect forward secrecy, the session key depends on the secrets x-values from both parties.
If an attacker injects an old (captured) key exchange, the session key would be different, because the attacker cannot influence which random x-value the server (or the client) choose.

Quote:
Sorry, I am a bit confused here, remember I want not only to make sure my plaintext is correct, but I also want to detect if an attacker tried to modify the encrypted container as he cannot get inside to corrupt the plaintext, so he can corrupt only the container and/or the signature.

You can build a HMAC of the encrypted container. When an attacker corrupts the ciphertext, the MAC would be a different one.
But, when he doesn't have the secret key for the HMAC, he cannot calculate a new and valid MAC of the corrupted ciphertext.

But symmetric encryption is very fast (with Rijndael/AES you can get on a modern PC upto 600 Mbit/s), so a verification of the ciphertext is normaly not needed, as long as you verify the plaintext.


Quote:
So if he is unable to create a collided package using an existing signature, there is no way for him (without the server's private key) to trick the client into accepting the package?

Right.


Quote:
1. What is the advantage/practical use for a combination of 2 key pairs (A public + B private and vice versa), only speed?

Asymmetric encryption is extremly slow, instead symmetric encryption is extremly fast.

RSA with a 1024-bit public key, has an encryption speed of arround 2 Mbit/s, symmetric algorithm can encrypt with upto 300 - 600 Mbit/s.
And the decryption with RSA is even slower, just 0,7 Mbit/s.

When you wanna encrypt 10 MB with RSA, you need ~40 seconds, and for decryption ~800 seconds.
A symmetric algorithm needs just 0.2 seconds.



@2:
When the attacker has the private key of the signatur algorithm, he can calculate valid signatures, because for this you need just the private key Wink

When he doesn't have i, he cannot calculate valid signatures.

But just with plaintext/chiphertext pairs, he cannot calculate the private key or build new, valid signatures.
The whole secruity of certificates and signatures based on the secrecy of the private key(s).[/b]


PS: I recommend to use SSL/TSL, it unite all you need, message integrity, injection protection, authentication and so on.
It suffices when the server has a certificate and when the client verfiy the signatur of this certificate (but then everyone, also an attacker, can download the updates).
There are many SSL-libraries, which are realy easy to use (e.g. look for an OpenSSL Wrapper when you don't wanna use the free & open source cryptlib of OpenSSL, because you prog. is written in a different language then C).
Back to top
View user's profile Send private message
Searcherx
Just Arrived
Just Arrived


Joined: 09 Jun 2007
Posts: 0


Offline

PostPosted: Thu Jun 14, 2007 10:46 pm    Post subject: Reply with quote

Thank you Elderean once again, you've been very helpful, all is clear now Wink

Thanks again
-src-
Back to top
View user's profile Send private message
Display posts from previous:   

Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Cryptographic Theory and Cryptanalysis - Internal and Transmission Security All times are GMT + 2 Hours
Page 1 of 1


 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Community Area

Log in | Register