I am using TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite, and I have sucessfully finished the handshake process, so i should have the correct KEYS for the server side and client side, but when i use the server write key and iv to encrypt the data and put under record layer(applicaiton type) send to client, but when i use wireshark ssl debug, i found out that wireshark didn't decrypt the application data correctly, wonder is the application data use a different key to do the encryption and decryption? Thanks
I have finally found the problem, TLS 1.0 used the last block of encrypted data as new IV to encrypt the data. its a little surprised, the encrypted data is visible on the network, so anyone capture that data can find out the IV.
Related
I'm trying to decrypt UDP packets for a multiplayer video game. When loading into a game session, a DTLS handshake occurs where, in Wireshark, I usually see the Client and Server agree on ChaCha20 Poly1305 encryption. The game actually live logs a "key" in a log file, which is 32 bytes long hex-coded, along with an HMAC and IV. At this point I'm not sure what to do. I tried decrypting individual messages in Python with some cryptography libraries but I realized that might be silly upon learning DTLS, or at least TLS packets, cannot be decrypted independently. I know I can possibly have Wireshark point to a file or add a key to live decrypt something, but have not had luck doing so. I started this process from basically no knowledge on internet security protocols or cryptography and have learned a lot but am at a standstill, and just want to make sure I'm not far off-base here.
Wireshark screenshot of handshake
It depends on what the game is actually writing to the file. Wireshark has support for decrypting TLS/DTLS using the RSA private key, the premaster secret or master secret. If the log file contains the premaster or master secret, then you should be able to shoe-horn it into wireshark, and decrypt the stream from there.
If it isn't, then you'll need to work out what it actually is first, and then it's a bit more of a manual job to get at the data.
I have been working to create an RTP/RTCP client and server implementation as a project. I have hit a block when it comes to parsing incoming packets because I am having trouble understanding the encryption method. I have read RFC 3550 several times. Section 9 explains confidentiality and security. I've read about DES-CBC mode here.
Observations I've deduced about encryption
RTP/RTCP packets are encrypted as a unit, meaning ALL bytes are encrypted
Encrypted RTCP packets are prefixed with a 32-bit random number
Encrypted RTP packets are randomized by the timestamp and sequence number
DES-CBC is the default mode
DES-CBC mode requires a 64-bit key
DES-CBC mode requires a 64-bit initialization vector (IV)
DES-CBC has a block size of 64 bits
What I'm confused about:
DES-CBC states that it uses the "Privacy Enhancement for Internet Electronic Mail" (PEM) protocol, but the RTP RFC makes no mention of this. In addition, the encryption diagrams do not include any PEM headers or elements.
Diagram
UDP packet UDP packet
----------------------------- ------------------------------
[random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2]
----------------------------- ------------------------------
encrypted not encrypted
So my questions are:
Where does the key come from or what header elements make up the key?
What is the initialization vector for RTP/RTCP?
How do I parse an encrypted packet vs an unencrypted one?
Does RTP/RTCP use the PEM protocol? If so, how?
DES-CBC is a way for encrypting data and it can be used for all different protocols that need it's data to be encrypted.
Where does the key come from or what header elements make up the key?
Encryption keys are generated during connection initialization(at connect time) and can be generated using different ways but generally using Public key cryptography(ex: RSA and DH) and using certificates to prevent MITM attacks which is where the PEM standards are used.
What is the initialization vector for RTP/RTCP?
The IV(initialization vector) is randomly generated number that will be used to ensure that same plaintext will not be encrypted to same ciphertext if using same key (That's why it's Random).
How do I parse an encrypted packet vs an unencrypted one?
For encrypted packets you decrypt first using key(SECRET) you got at connection time then use IV which is sent with data packets(NOT secret) to reverse encryption process. For unencrypted packets you just parse the data since there is no KEY and IV data is just plaintext.
Does RTP/RTCP use the PEM protocol? If so, how?
PEM is not protocol in the sense as network protocols such SSH. This definition I think is accurate enough from wikipedia
Privacy-Enhanced Mail (PEM) is a de facto file format for storing and sending cryptographic keys, certificates, and other data, based on a set of 1993 IETF standards defining "privacy-enhanced mail.
so if your client is using encryption there is a very big chance that it will be using PEM standards for symmetric key initialization.
NOTE: timestamp and sequence number are different from IV these fields are RTP header fields which can serve a similar purpose but they are different from CBC mode IV.
I tried to understand how the implementation of srtp on the linphone application. When I activate the srtp feature on the phone, the digital data communication will be secured using the AES-ICM encryption method. But I found something interesting in its implementation.
The encryption process in the AES-ICM method works with xor operations between keystream suffix and RTP packet payload (plaintext) to produce ciphertext. The encryption key is used in an aes operation to generate a suffix keystream. This ciphertext will then be sent from the sender to the receiver.
In the implementation of SRTP, I display the plaintext, key and ciphertext used or generated by the sender and receiver. I found the difference between the ciphertext and key for each packet in the sender and receiver. When a plaintext is encrypted using a specific key and produces a ciphertext in the sender, the receiver, the ciphertext that is received and the key that is used has a difference. However, the strange thing that I found was that the results of the decryption of the plaintext on the receiver are the same plaintext as what is encrypted in the sender. And the voice that was communicated arrived, can anyone explain this why?
Code to display text : https://pastelink.net/1re6m
Log endpoint 1 : https://pastelink.net/1re93
Log endpoint 2 : https://pastelink.net/1re9c
Then, I tried to deactivate the encryption feature by using the srtp_cipher_encrypt code in the srtp_protect_mki and srtp_cipher_decrypt modules in the srtp_unprotect_mki module. Isn't that as if it didn't encrypt the payload like the Null Cipher is implemented? However, the same ones found are ciphertext and plaintext that have nothing in common with the sender and receiver as well as the sound on the speakers that contain noise without being able to identify what is being sent. Can anyone explain this too?
For example, the first plaintext used for encryption at endpoint one is:
"d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d ......"
generate ciphertext:
"7c8fb6c2f783e5fdb34116bb5d5ce27475bf400b4 ........"
then at endpoint 2 which acts as a receiver, the first ciphertext received is
"e2bd90a5275e44ac2d4fc332cfff138e743c39c80b ......."
generate plaintext:
"d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5 ......."
Thank you
I find the answer from another forum. In my case this is happening because the VOIP server which is I am using Asterisk will decrypt every incoming packet for processing before sending it back. This package will then be re-encrypted by Asterisk before being sent to its final destination. Every packet that enters will be decrypted and the one that exits the asterisk will be re-encrypted. So, in my case, this happened because of the voip server technology used.
Is it safe to send a mobile client an AES Key and IV from the server to use for encrypting sensitive data? The key and IV would be sent using TLS. This key would be used for encrypting data from end to end.
Update:
My requirements have actually changed, so I don't need to do this, but the solution I came up with was actually to have the client send a public key to the server over tls. Then the server could encrypt the keys with that public key and send them back to the client.
It would be as secure as any data in TLS. It also depends on how much your client trusts this TLS, which may not have two sided authentication.
But basically sending the key this way doesn't add much to using TLS. If TLS is insecure then the AES key is insecure. If it isn't then the AES key is secure...but TLS was already secure. There might be a slight advantage if you'd use a ciphersuite that provides forward security (DHE_ or ECDHE_).
But mostly, if you send anything, you'd send a public key such as a PGP key. The person on the other hand still has to trust the sender of course (i.e. by validating the fingerprint) but if the TLS connection is insecure then leaking the public key would at least not break anything encrypted using it.
I'm trying to use the Qt Cryptographic Architecture to generate public/private key pairs for nodes, and want to have a protocol in which nodes confirm that a message came from a given source (public key) by issuing a challenge to ensure they are the owners of the corresponding private key. I'm a little stuck on the actual syntax for QCA though ...
This should get me a private key, from which I can also get the public key:
QCA::KeyGenerator generator;
QCA::PrivateKey privateKey = generator.createRSA(1024);
Does QCA already have some sort of challenge protocol built in? If so, how can I use it? If not, how can I apply some of the standard cryptographic challenge protocols using these keys? I'm really just trying to demo a simple security concept - I'm not looking for anything complicated or even particularly robust.
Also, this is a side question, but since I don't need encryption, should I be opting for DSA as opposed to RSA?
There are more than one of doing that. But since all clients already have their asymmetric key pairs you may deploy two-way TLS in establishing connection.
In this scheme both client and server allow establishing connection only, if they trust certificates (public keys) of each other. This guarantees client authentication and non-repudiation.
From your side you will need to provision server certificate to all clients and all client certificates to the server. To avoid dealing with certificate authorities, certificates could be self-signed.
QCA has examples for TLS client and server.