Re: TLS application data MAC
Look at the Appendix -- Sample Code in http://www.ietf.org/rfc/rfc2104.txt Avinash Agarwal wrote: Hello all, I'm trying to figure out how to generate the MAC for application data in TLS v1. The rfc (2246) says at ยง F.2 "protecting application data" "Outgoing data is protected with a MAC before transmission. To prevent message replay or modification attacks, the MAC is computed from the MAC secret, the sequence number, the message length, the message contents, and two fixed character strings." What are the "two fixed character strings"? TIA Regards, Avinash __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: TLS application data MAC
Hi Avinash, The paragraph you mentioned is little bit vague, better look at 6.2.3.1 from the same RFC; below is a fragment from 6.2.3.1 paragraph: .. The MAC is generated as: HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment)); where "+" denotes concatenation. . The "two fixed character strings" are 'type' and 'version'; I implemented it (in C++) just as specified above and it works. Dragos. __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: TLS application data MAC
Hello dragos, Thanks for the input. The MAC generation mentioned below works alright for MAC generation of Client/server hanshake finished messages. However for the MAC generation for the TLS app data this is not working. Any pointers on what could be wrong? Regards, Avinash -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dragos liciu Sent: Thursday, September 16, 2004 12:07 AM To: [EMAIL PROTECTED] Subject: Re: TLS application data MAC Hi Avinash, The paragraph you mentioned is little bit vague, better look at 6.2.3.1 from the same RFC; below is a fragment from 6.2.3.1 paragraph: .. The MAC is generated as: HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment)); where "+" denotes concatenation. . The "two fixed character strings" are 'type' and 'version'; I implemented it (in C++) just as specified above and it works. Dragos. __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com <http://messenger.yahoo.com> __ OpenSSL Project http://www.openssl.org <http://www.openssl.org> User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: TLS application data MAC
Before seq no, there should be either the client MAC or server MAC (depending on who you are). Avinash Agarwal wrote: Hello dragos, I think you are referring to the problem with decrypting/encrypting the TLS app data...I faced the problem but i was finally successful in decrypting/encrypting the TLS app data... However my question pertained to generation of the MAC data to verify a message. say i need to send this data "0x01 0x07 0x00 0x05 0x01" in the TLS app data. To send this I also need to create a MAC. Assuming I'm implementing a server..I use the server_auth_key and HMAC_MD5 as my MAC algo. To generate the MAC I do the following Key for HMAC_MD5 = server_auth_key Input msg to MAC algorithm { seq no = 0x00 (8bytes) Type = 0x23 (application data) version = 0x0301 Length = 0x05 Data = 0x01 0x07 0x00 0x05 0x01 } The MAC generated from the above does not match ..what the client generates for verification. this is the same case when i try to generate a MAC on the server for any msg recieved from the client. I'm stuck in the MAC generation part. Can someone help me out ? Regards, Avinash -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 9/16/04 10:38 AM Subject: RE: TLS application data MAC Hi Arvinash, I think you have now exactly the same kind of problem I had when I implemented the client: the first TLS app data message the client was sending to the server (after FINISHED messages) couldn't be decoded correctly by the the server; this behaviour was caused by the fact that I was using the same iv (initialization vector) for all the records send by the client (I was using 3DES cipher for symmetric encryption). Please check this thing on your code...I have a feeling that this might be your problem. If this is indeed the problem, can be solved according to the RFC's 6.2.3.2 paragraph: ... Note: With block ciphers in CBC mode (Cipher Block Chaining) the initialization vector (IV) for the first record is generated with the other keys and secrets when the security parameters are set. The IV for subsequent records is the last ciphertext block from the previous record. .. So for each new app data record (after FINISHED message) you want to encrypt/decrypt, the IV will change (is the last ciphertext block from the previous record). For stream ciphers (like RC4), the trick is different: this time there's no IV, but you have to keep cipher context between records. Also keep in mind this is only for TLS 1.0; TLS 1.1 (still a draft) have a different way to compute IV. Let me know if this solves your problem. Dragos __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: TLS application data MAC
Hi Avinash, Sorry for late reply, but I didn't follow the emails on weekend. You sent: . Key for HMAC_MD5 = server_auth_key Input msg to MAC algorithm { seq no = 0x00 (8bytes) Type = 0x23 (application data) version = 0x0301 Length = 0x05 Data = 0x01 0x07 0x00 0x05 0x01 } The only problem I see in your email is that the 'Length' field seems to be only 1 byte long, but it should be 2 bytes long instead (see RFC); Please let me know if this is indeed the problem. If no, we'll dig further; you are very close. Also I supposeed you've verified that keys calculated by both server and client match. Dragos. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: TLS application data MAC
Hello Dragos, I was able to solve this issue.. thanks to Niklas and Goran :) I was using the wrong sequence number. Once again thank you everyone for your help. Regards, Avinash -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dragos liciu Sent: Tuesday, September 21, 2004 12:11 AM To: [EMAIL PROTECTED] Subject: RE: TLS application data MAC Hi Avinash, Sorry for late reply, but I didn't follow the emails on weekend. You sent: . Key for HMAC_MD5 = server_auth_key Input msg to MAC algorithm { seq no = 0x00 (8bytes) Type = 0x23 (application data) version = 0x0301 Length = 0x05 Data = 0x01 0x07 0x00 0x05 0x01 } The only problem I see in your email is that the 'Length' field seems to be only 1 byte long, but it should be 2 bytes long instead (see RFC); Please let me know if this is indeed the problem. If no, we'll dig further; you are very close. Also I supposeed you've verified that keys calculated by both server and client match. Dragos. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com <http://mail.yahoo.com> __ OpenSSL Project http://www.openssl.org <http://www.openssl.org> User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]