banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Forum Index Thông tin new bugs và exploits BEAST: Surprising crypto attack against HTTPS  XML
  [Article]   BEAST: Surprising crypto attack against HTTPS 26/09/2011 12:34:11 (+0700) | #1 | 247737
mrro
Administrator

Joined: 27/12/2001 05:07:00
Messages: 745
Offline
[Profile] [PM]
Chào bà con,

Như đã có lần nói trên HVA, tuần vừa rồi mình và một người bạn vừa trình bày BEAST, một cách tấn công chọn bản rõ mới vào HTTPS. Các bạn có thể xem demo ở http://www.youtube.com/watch?v=BTqAIDVUvrU và tìm đọc phiên bản rò rỉ của paper ở http://www.insecure.cl/Beast-SSL.rar. Bài dưới đây là mình viết trên blog cá nhân về quá trình nghiên cứu BEAST. Đọc nó mình nghĩ là thú vị hơn đọc paper smilie. Ở đây thiếu mấy cái liên kết, nên bạn nào muốn truy cập mấy cái liên kết thì qua http://vnhacker.blogspot.com/2011/09/beast.html.

-m

---

So we gave a talk and a live demo at ekoparty last week to show how BEAST exploits a weakness in SSL to decrypt secret cookies.

Please note that BEAST does not do any harm to remote servers. In fact, no packet from BEAST has ever been sent to any servers. We chose PayPal because they do everything right when it comes to server-side SSL, and that is good to demonstrate the power of BEAST, which is a client-side SSL attack. We reported the vulnerability to browser, plugin and SSL vendors several months ago (CVE-2011-3389).

Current version of BEAST consists of Javascript/applet agents and a network sniffer. We have some choices for the agent. At the time we reported the bug to vendors, HTML5 WebSockets could be used to build a BEAST agent but, due to unrelated reasons, the WebSockets protocol was already in the process of changing in such a way that stopped it. We can't use the new WebSockets protocol shipped with browsers. We use a Java applet in this video, but please be aware that it may be possible to implement a Javascript agent with XMLHttpRequest as well. Why don't you take a look? smilie

Note that it is relatively easy to run a script or an applet in your browser without you doing anything (e.g, by intercepting any HTTP requests from your browser.) After all, each agent is just a piece of Javascript or an applet. Once an agent has been loaded, BEAST can patiently wait until you sign in to some valuable websites to steal your accounts.

In order to make the Java applet agent work, we have to bypass the same-origin policy (SOP). Some people have gotten the impression that BEAST required an SOP bypass bug to work and so it's not a threat by itself. That's not true. It is well known that even with a SOP bypass in Java, you can't read existing cookies. You can send requests and may read responses (which may include new cookies), but no, you can't read existing cookies. In the video (and the live demo as well,) we show clearly that we decrypt _existing_ cookies that were already stored in the browser's cookie jar. During our research, we indeed found a Java SOP bypass. We wanted to focus on more important parts of BEAST such as the actual crypto attack and optimizations, so we stopped looking for alternatives, and used the SOP vulnerability to make an agent.

A. Shamir (the S in RSA) once said "Cryptography is typically bypassed, not penetrated," and please keep reading if you are curious what happened during our anecdote of penetrating crypto.

It began with the alleged backdoor in OpenBSD's IPSEC stack. One day in late December 2010 Juliano sent me an email telling me that he got a new idea. He was at some beach in Indonesia reading tls-cbc.txt (I know that beach and TLS and CBC should not appear in the same sentence but, well, maybe he's not very interested in bikinis) and he came up with the chosen-boundary attack. In hindsight, it's obvious that somebody would think of that when they read about Dai's attack. In hindsight, however, everything is obvious. It takes somebody like Juliano to have such a good idea. I am so lucky that he always shares his ideas with me. I wrote some test cases (using the wonderful tlslite library), and after some hours, my conclusion was... it can't work in browsers. I then moved to the States, and was busy with new life, new job and schooling, so I didn't have time to research that idea any further, even after Juliano kept asking me to check it again. Don't listen to me if I tell you your attack can't work smilie. Don't listen to anybody telling you that.

Fast forward to early April. I was working on some project at Matasano, and some SSL code that I saw that day made me realize that I wrote wrong tests for Juliano's idea. In fact, it seems that I didn't quite understand it back then. As soon as I got back home, I re-read Juliano's email, my notes and scripts. I decided that I needed to make it work with pen and paper first, so I drew some diagrams. The result looked hopeful. I then modified the test cases, re-ran them, and for the first time, I saw that chosen-boundary attack may work. That moment was so wonderful. It turns out that I had to "reverse" the idea to make it "compatible" with browsers, and after some more hours, not only I saw that the attack is possible, but I also understood which conditions I need to make it really work. The conditions looked easy too. I was very excited. I would have screamed loudly hahaha. I took note of what I had seen so far, and sent it to Juliano.

At first, Juliano didn't understand my note (because it's a reverse of his idea,) but he caught up very quickly, and he agreed that it looks doable. So the main condition is to be able to send two SSL records in the same cookie-bearing request (if you've read the leaked draft, we call this the blockwise privilege.) We were both very excited, because at that moment we know that it is just a matter of browser features for us to create a reliable exploit for something that people have thought un-exploitable in years.

I collected a list of browser features and plugins that allow me to send cookie-bearing requests. I took a look at the Browser Security Handbook by Michal Zalewski, and found some candidates: Javascript XMLHttpRequest, Java URLConnection, Flash URLRequest, and Silverlight WebClient API. We really wanted to make the attack work with native Javascript, so we spent a lot of time on XMLHttpRequest object. At some point, Juliano and I were even reading C++ source code of various browsers (which is even harder to understand than assembly as a friend once said.) Maybe we've missed something really obvious, but we've never made XMLHttpRequest work the way we need. It was both surprising and frustrating that it is so hard to do request streaming in modern browsers. People have to invent a lot of ugly bitches that known as Comet techniques. I studied every single one of them, but none of them meets what we need. I also studied HTML5 WebSockets, then concluded that it's not what I need because it includes a \x00 byte in front of every packet. More about WebSockets in a moment.

So I moved on to Java URLConnection. I'd never written an applet before, but researching is doing exactly things that you haven't done before. So I wrote an applet, and tried to make it perform the blockwise step. The Internet is really helpful. I found a wonderful URLConnection mini-guide in Stack Overflow. I also wrote a small SSL server to test my applet. It worked as expected. I could open a request, append more data to it as long as I want, and each time I "flush" the output stream, Java would send out a record in the same SSL connection. So wonderful, but I want more. I want something that works without any plugins. Once again I started writing tests for XMLHttpRequest, reading C++ code, or studying Comet. Rinse and repeat. Nothing worked.

One day while in the shower, I realized that those things haven't worked simply because they can't work. That's why people have to invent WebSockets. Hmm, why couldn't I use WebSockets? I re-read my note. So they have a \x00 prefix, which prevents me from fully controlling the chosen block. I remembered that Bellare et al. also had the same problem when they tried to attack SSH, so I re-read their paper. I was quite disappointed to know that they didn't describe any practical way to solve that problem. Then I came up with the idea of chaining of predictable IV. I wrote a small WebSockets simulator to test it, and it works. Not very fast though, since WebSockets requires that my chosen block to be a valid UTF-8 string. It's funny that we also had to deal with UTF-8 in the ASP.NET exploit. Anyway, it doesn't need any plugins. It was late April.

We split the work. I wanted to work on the paper, and Juliano wanted to work on the exploit. I started writing right away, but Juliano had to delay the exploit several months later. He got a name for it anyway. "This thing is so complicated. I would like to call it B.E.A.S.T so people kind of get stuck calling it 'the BEAST attack'. We can figure out what BEAST means later."

Writing in English has never been easy for both of us. It took us several months with a lot of help from friends to finish the ASP.NET paper, and I couldn't believe that I had to write another one even before releasing that paper. But I did eventually. Along the way, I found Bard's papers, which was extremely helpful for me. I read his paper carefully. So many "We believe". I have to confess that I am a non-believer, so I made a rule for myself: no "We believe" in my paper. Anyway, although Bard's attacks can't work, his papers were written in very nice English. So I stole a lot of phrases, expressions and statements from him. Of course I cited him many times.

So I kept writing, and Juliano helped with editing. By mid May, we finally had something good enough to ask for review from friends. I guess that no "We believe" is a good rule, since everybody said that the paper is easy to understand. We also got an awesome review from Kenny Paterson. If you happen to write a crypto paper, and need some cryptographer to review it, you may want to ask Kenny. He's very friendly, encouraging, and his review always teaches us a lot.

So we got a not-so-bad paper, but still no actual exploit because Juliano was still in some beach somewhere. We agreed that we should contact browser and SSL vendors early so that they can work on the patch, since we planned to (but didn't) release something in July. We sent the paper to Google, Mozilla, Apple, Microsoft, Opera and Oracle. All of them responded very quickly, which is pretty impressing. Mozilla created bug 665814, and it became the discussion board of all people working on the fix. Later I discovered that there were also people from IETF and other vendors that we didn't contact.

It turns out that fixing this is not easy, because every proposed solution is incompatible with some existing SSL applications. OpenSSL has already included a fix several years ago, but it is turned off by default, thanks to Internet Explorer 6's broken SSL implementation. Somebody also pointed out that due to another attack released in March, the WebSockets protocol was already in the process of changing in such a way that stopped our attack. People kept asking for a working PoC, but we could not give them anything. At some point, it seemed that no vendor wanted to patch this. We also started losing interest in convincing them. We got more compliments from cryptographers we contacted.

We didn't release anything in July as planned, since nothing has been fixed. Instead we went to BlackHat, won a pwnie for the ASP.NET bug, delivered a presentation on the attack at Matasano's private dinner. People liked it. We got several follow-up emails and an invitation to present it again at some internal conference of a client. Juliano and some other friends rooted all servers and yet lost their CTF game. Still no actually BEAST. "We can work together on BEAST when I visit you next week", but we ended up drinking all nights. So many hi 5...

Then Juliano submited the talk to ekoparty. Opera patched. We got excited. That was five weeks ago.

Juliano told me that the talk got 10/10 rating from all of the judges, and he felt that it's time to give birth to BEAST. Since WebSockets is not a good option anymore, and there was so little time to research other alternatives, we agreed that we should focus on Java and Silverlight. He worked and worked and worked. It turns out that BEAST is not easy to code. At some point, Juliano had to install Windows and Visual Studio to write a Silverlight applet in, cough cough, VB.NET. Well, he has to do things he's never done before.

BEAST finally decrypted the first byte of some cookies. It is so surreal to witness some idea that exists only in your mind actually evolves into working code. Moments like this are very rewarding, and it makes researching very worth doing. Juliano was so tired, so I asked him to send the code to me. This is why we've enjoyed doing things together. We can make progress as long as there is at least one guy up. He has done the heavy work, now it's my turn to baby-sit BEAST.

I installed Eclipse, learned Java, and started hacking the code. Since Juliano stopped as soon as BEAST decrypts the first byte, I had to fix bugs to make it decrypt more bytes more reliably. The next thing I did was to find a way to bypass the same-origin policy (SOP) with some agent. A friend was so generous that he gave me one of his Java 0-days to bypass SOP. Anyway, that bug has a dependency that we couldn't satisfy, so I had to find another one. I started reviewing JVM's source code. Honestly, I didn't expect to find a SOP bypass, but I did. What interesting is that the bug is very good for BEAST, but not so good for other types of attackers. You need to be able to do MiTM to use it. Well, that makes sense when you know that I found the bug when I was MiTM-ing a Java applet. I could look for other ways to create an agent, but both of us agreed that we should focus on optimizations. I needed to make BEAST fast. The version that Juliano sent me was so slow that all we got were expired cookies. BEAST is just a baby, it deserves fresh cookies. I spent the last week or so working on that. As you see in the demo, BEAST now takes minutes to decrypt very long unexpired cookies.

In summary, we had an idea, and we've done several things we've never done before to make it work. That's our story of penetrating crypto. Thank you for your time.

Thanks to Marsh Ray and Juliano Rizzo for reading and editing drafts of this.

Update 9/26/2011: correct some spelling and grammar errors.
http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html
[Up] [Print Copy]
  [Article]   BEAST: Surprising crypto attack against HTTPS 26/09/2011 14:20:31 (+0700) | #2 | 247745
vd_
Member

[Minus]    0    [Plus]
Joined: 06/03/2010 03:05:09
Messages: 124
Offline
[Profile] [PM]
@mrro
Ngưỡng mộ mrro.

Tui đang đợi có thêm chi tiết để hiểu thêm và tìm cách mitigation.
Theo bài viết trên ImperialViolet (http://www.imperialviolet.org/2011/09/23/chromeandbeast.html) thì server ssl sử dụng cipher suit RC4 (?) sẽ không bị ảnh hưởng.

Bữa hổm tui thử config server để disable tất cả cipher suit có CBC (thiệt xấu hổ, không rành lằm nên nhắm mắt cái cipher suit nào có CBC là tắt hết) thì chỉ có 1 số browser mới như Chrome 14, Firefox 6 access được, còn các browser cũ ngủm hết, đành phải set lại như cũ. Hy vọng sớm có thêm những bài phân tích cho newbie như tui để hiểu thêm.

Một lần nữa chúc mừng mrro và cho phép tui bày tỏ sự ngưỡng mộ.
[Up] [Print Copy]
  [Article]   BEAST: Surprising crypto attack against HTTPS 27/09/2011 02:56:07 (+0700) | #3 | 247773
boom_jt
Member

[Minus]    0    [Plus]
Joined: 02/08/2007 23:51:10
Messages: 125
Offline
[Profile] [PM]
Mình cũng vừa đọc được thông tin về BEAST xong, liền vào hva để đọc thêm. Chúc mừng mrro và đồng tác giả smilie Ngoài ra các lỗi 0-day tìm được cũng không tệ chút nào nhé.
[Up] [Print Copy]
  [Article]   BEAST: Surprising crypto attack against HTTPS 27/09/2011 04:00:28 (+0700) | #4 | 247774
boom_jt
Member

[Minus]    0    [Plus]
Joined: 02/08/2007 23:51:10
Messages: 125
Offline
[Profile] [PM]
Ok, để boom_jt thử giải thích qua cách tấn công nhé, version đơn giản thôi, tất nhiên là lấy từ việc đọc hiểu paper :

BEAST mà mrro et al. (lol) tìm ra nhằm vào mã hoá đối xứng sử dụng CBC mode, tức là mã hoá theo khối, trong đó kết quả mã hoá của block trước sẽ được dùng để thay đổi kết quả mã hoá của khối tiếp theo.

Điều kiện thành công là attacker cài được 1 agent vào browser của victim. Agent này có khả năng yêu cầu browser thực hiện request HTTP và đọc nội dung request này. Agent này có thể đơn giản là 1 đoạn code javascript, cài vào browser theo cách tấn công XSS. Điều kiện tiếp theo là attacker phải bypass được SOA (same-origin policy) của browser, do đoạn code javascript không nằm trên cùng server với trang web HTTPS.

Các bước tấn công :
Attacker yêu cầu browser thực hiện request đến server HTTPS : POST /AAAAAA HTTP/1.1<CR><LF><REQUEST HEADERS><CR><LF><REQUEST BODY>

Nội dung browser gửi đến server sẽ có dạng C1|C2|C3|...|Cn là các khối được mã hoá. Trong đó
+ C1=encrypt("POST /AA")
+ C2=encrypt("AAAA HTT")
+ C3=encrypt("P/1.1<CR><LF><X>")
với <X> là kí tự đầu tiên của header tiếp theo.

Để ý rằng trong C3 này, thì 7 kí tự đầu tiên đều đoán được. Nhiệm vụ của attacker bây h để tìm ra <X> sẽ là yêu cầu browser gửi các khối [Cn.C2."P/1.1<CR><LF><Y>"] được mã hoá, với <Y> là 1 kí tự được phép trong header, sau đó so sánh đoạn mã hoá này với C3.

Chú ý rằng khi mã hoá khối B = "P/1.1<CR><LF><Y>" này, attacker phải thực hiện trước Cn.C2.B rồi mới yêu cầu browser gửi, do Cn ảnh hưởng tới kết quả mã hoá của block tiếp theo, còn C2 ảnh hưởng tới kết quả mã hoá của C3. Làm như vậy thì mới so sánh kết quả mã hoá của browser với C3 chuẩn xác được.

Khi attacker có được 1 đoạn mã hoá do browser gửi trùng với C3, đồng nghĩa với việc attacker giải mã được <X>

Như vậy, attacker chỉ cần liên tục thực hiện các request rồi so sánh, từ đó sẽ giải mã được nội dung request byte-by-byte. Với ví dụ như trên, chắc các bạn cũng đoán được request tiếp theo cần phải có dạng thế nào, để kí tự cần giải mã tiếp theo nằm đúng vào vị trí cuối cùng trong block.

Trong trường hợp demo của mrro, đó là việc giải mã lấy cookie (được gửi trong mọi request) của paypal để đăng nhập.

Như vậy, có thể nói attacker đã bypass được HTTPS, lợi dụng đường truyền và tính toán của browser để giải mã theo kiểu Chosen-plaintext attack mà không cần tấn công trực tiếp vào mã hoá.
(A. Shamir (the S in RSA) once said "Cryptography is typically bypassed, not penetrated", lol)

Có gì sai sót mong các bạn chỉ giáo. Và một lần nữa chúc mừng mrro smilie
[Up] [Print Copy]
  [Article]   BEAST: Surprising crypto attack against HTTPS 11/10/2011 03:15:52 (+0700) | #5 | 248502
mrro
Administrator

Joined: 27/12/2001 05:07:00
Messages: 745
Offline
[Profile] [PM]
@boom_jt, vd_: xin cảm ơn smilie.

đây là loạt bài về BEAST mình đang viết trên http://procul.org/blog.

http://www.procul.org/blog/2011/09/30/beast-1/

http://www.procul.org/blog/2011/10/06/beast-2/

1. Giới thiệu

Bây giờ nhắc đến Netscape chắc ít người còn nhớ, nhưng trong giai đoạn đầu của cuộc cách mạng World Wide Web hồi giữa những năm 1990, Netscape có vị thế như Google hay Facebook bây giờ. Rồi cuộc chiến trình duyệt lần thứ nhất nổ ra và Netscape là kẻ bại trận dưới tay gã khổng lồ Microsoft. Từ chỗ chiếm hơn 90% thị phần trình duyệt với sản phẩm chủ lực Netscape Navigator, Netscape giờ đây không còn được mấy ai biết đến. Dẫu vậy di sản mà họ để lại vẫn rất vĩ đại.

Netscape tạo nên Mozilla và đóng góp mã nguồn vào các phiên bản trình duyệt đầu tiên của tổ chức này. Javascript, ngôn ngữ lập trình được sử dụng phổ biến nhất trên WWW, cũng là một sản phẩm của Netscape. Vậy thì Netscape có liên quan gì đến tiêu đề của bài viết này? Secure Socket Layer (SSL), bộ giao thức giữ vai trò quyết định cho sự hình thành và phát triển của thương mại điện tử, nói không ngoa cũng là niềm hi vọng của cả thế giới về sự an toàn và riêng tư trên Internet, cũng được tạo ra ở Netscape.

Netscape làm xong SSL 1.0 từ năm 1994, nhưng phiên bản này chưa bao giờ được công bố. SSL 2.0 được công bố rộng rãi vào tháng Hai năm 1995. Không lâu sau đó người ta phát hiện ra nhiều vấn đề nghiêm trọng với bộ giao thức này nên vào năm 1996, Netscape phát hành SSL 3.0 với nhiều cải tiến nhằm sửa các lỗ hổng ở SSL 2.0. IETF, tổ chức quy định các tiêu chuẩn trên Internet, chuẩn hóa SSL và tạo ra Transportation Layer Security (TLS) và phát hành TLS 1.0 vào năm 1999.

Năm 2002, trong một email với nhan đề “An attack against SSH2 protocol” -1- gửi đến nhóm phát triển OpenSSH, Wei Dai mô tả một tấn công chọn bản rõ (chosen-plaintext attack) vào cơ chế hoạt động CBC -2- (cipher-block chaining) của các mã khối (block cipher). Tấn công của Wei Dai dựa trên một ý kiến của Phillip Rogaway đưa ra từ năm 1995, khi ông bàn về các điểm yếu trong việc sử dụng mật mã của giao thức IPSEC. -3-

Không lâu sau đó, Bodo Möller, lập trình viên của dự án OpenSSL, nhận thấy tấn công của Rogaway-Dai có thể áp dụng được cho giao thức SSL 3.0 và TLS 1.0. Ông đề xuất một giải pháp khá thông minh, tạm gọi là giải pháp OpenSSL -4- (chi tiết tôi sẽ nói sau) và tích hợp giải pháp đó vào phiên bản OpenSSL 0.9.6d phát hành giữa năm 2002. Tuy vậy, do gặp vấn đề về tương thích với trình duyệt Internet Explorer 6 của Microsoft (ai mà không gặp vấn đề này?), nên giải pháp OpenSSL thường bị gỡ bỏ trong các cài đặt của OpenSSL.

Ngoài OpenSSL ra, không một nhà phát triển SSL nào quan tâm đến tấn công Rogaway-Dai, vì ý tưởng này được xem là chỉ có ý nghĩa về mặt lý thuyết. Không ai nghĩ rằng có thể xây dựng được một tấn công thực thụ vào các ứng dụng SSL từ ý tưởng này, ngoại trừ Gregory Bard. Lần lượt trong hai năm, 2004 và 2006, Bard thử áp dụng tấn công Rogaway-Dai vào SSL trong trình duyệt -5- và SSL trong VPN -6-. Mặc dù Bard đã cho thấy được “diện mạo” của tấn công Rogaway-Dai khi áp dụng vào SSL sẽ ra sao, nhưng các tấn công của Bard vẫn không thể áp dụng được trong thực tế (tôi sẽ quay lại điểm này sau).

Trong khi đó, để ngăn chặn triệt để tấn công Rogaway-Dai, IETF quyết định chỉnh sửa TLS 1.0 và phát hành TLS 1.1 vào năm 2006. Đây là một điều chỉnh lớn, bởi vì TLS 1.1 (và TLS 1.2) không tương thích với TLS 1.0 và SSL 3.0. Đối với IETF, tấn công Rogaway-Dai, tồn tại trong hơn 11 năm từ những phiên bản đầu tiên của SSL, xem như là đã được giải quyết rốt ráo. Cho đến khi B.E.A.S.T được giới thiệu trong thời gian gần đây.

BEAST áp dụng Rogaway-Dai để tấn công vào giao thức HTTPS. Nếu như trước đây các tấn công vào HTTPS vốn chỉ tập trung vào việc khai thác điểm yếu của hạ tầng khóa công khai/chứng chỉ số thì BEAST thực sự giải mã các yêu cầu mà trình duyệt gửi đến máy chủ xuyên qua HTTPS, rồi lấy trộm các bánh quy HTTP (HTTP cookie). Trong số các ý kiến bình luận về BEAST, tôi thích nhất ý kiến của Karsten Nohl -7-:


The TLS exploit is a neat fusion of two streams in vulnerability research: Cryptanalysis and client-side attacks. In this case, a known client-side problem–namely (that) Web sites are not shielded from one another–is used to break an assumption in cryptography–that a user’s computer will not attack the user.

Users already need to trust all the Web sites they are visiting due to vulnerabilities in their browsers (“drive-by exploits”) and in trusted Web sites (“tab-nabbing”). The new exploit strongly reminds us of this rule.
 


BEAST chỉ ra rằng: do tính chất liên kết của Web, rất dễ để thực hiện tấn công chọn bản rõ vào HTTPS. Một website bất kỳ có thể khiến trình duyệt của bạn mở một kết nối HTTPS đến một website khác và trong các kết nối đó, kẻ tấn công kiểm soát được phần lớn nội dung. Nói cách khác, BEAST có thể dễ dàng biến trình duyệt thành một encryption oracle, rồi cứ lần lượt gửi bản rõ vào, quan sát bản mã và lập lại (adaptive chosen-plaintext attack).

2. CBC - Tấn công Rogaway-Dai

2.1 CBC

Trong định nghĩa của mỗi mã khối (block cipher) đều có một thuật toán mã hóa nhận vào một khối bản rõ (plaintext block) có chiều dài b bit (gọi là chiều dài khối - block size) và một khóa có chiều dài n bit, rồi "nhào trộn" bản rõ và khóa lại với nhau để xuất ra một khối bản mã (ciphertext block) có b bit. Ví dụ như thuật toán mã hóa của mã khối nổi tiếng DES nhận vào một khối bản rõ có chiều dài 64 bit và một khóa có chiều dài 56 bit, rồi xuất ra một khối bản mã có chiều dài 64 bit. Vì lý do an toàn, các mã khối hiện đại thường có b = 128 và n >= 128, ví dụ như AES-128, AES-192, AES-256 (con số phía sau là chiều dài khóa; tất cả đều có chiều dài khối là 128 bit). Câu hỏi tự nhiên là mã hóa thế nào nếu bản rõ dài hơn b? Chẳng hạn như tôi cần phải làm sao nếu muốn dùng AES-128 để mã hóa bài viết này, vốn chắc chắn dài hơn 128 bit?

Để giải quyết vấn đề này, người ta dùng một phương thức hoạt động (mode of operation) của mã khối. Lưu ý rằng cùng một phương thức hoạt động có thể sử dụng cho nhiều mã khối khác nhau và ngược lại. Mỗi phương thức hoạt động sẽ định nghĩa hai thuật toán: mã hóa và giải mã. Các thuật toán này sẽ sử dụng mã khối và một khóa duy nhất để mã hóa/giải mã các khối dữ liệu có chiều dài lớn hơn b. Có nhiều phương thức hoạt động, phổ biến nhất là Electronic Code Book (ECB) và Cipher Block Chaining (CBC). Để mã hóa bằng ECB hay CBC, chúng ta cần phải thực hiện hai bước:

i) Nếu chiều dài bản rõ không chia hết cho chiều dài khối thì đệm thêm (pad) một số byte vào bản rõ (padding bytes) để tổng chiều dài chia hết cho $latex b$. Có nhiều cách đệm, phổ biến nhất là đệm theo chuẩn PKCS #5 -8-.

ii) Chia bản rõ ra thành từng khối và mã hóa theo thuật toán quy định trong phương thức hoạt động. Tôi sẽ đi vào chi tiết bước này trong cả hai phương thức ECB và CBC ngay bên dưới.

Điều thú vị là cả hai thao tác này đều đã tạo ra những tấn công rất nghiêm trọng vào các ứng dụng của mã khối trong thực tế. Ví dụ như đối với bước thứ nhất, ở Eurocrypt 2002 Serge Vaudenay đã trình bày tấn công padding oracle -9-, một tấn công chọn bản mã (chosen-ciphertext attack) cho phép kẻ tấn công có thể giải mã bất kỳ bản mã nào, chỉ với một điều kiện là nạn nhân tiết lộ kết quả gỡ đệm trong quá trình giải mã. Sau Vaudenay, đã có rất nhiều nghiên cứu khác về tấn công padding oracle -10-. Tôi và một đồng nghiệp cũng có hai nghiên cứu về đề tài này -11, 12-. Tuy vậy, BEAST không phải là một tấn công padding oracle, nên từ đây về sau chúng ta xem như các bản rõ đều đã được thêm đệm cho phù hợp.

Tôi dùng một số ký hiệu sau đây cho phần còn lại của loạt bài này:
Code:
Bản rõ được ký hiệu là M, bản mã là C. Bản rõ được chia ra thành m khối P_1, P_2,...,P_m. Các khối này sẽ được mã hóa thành C_1, C_2,...,C_m.

Hàm mã hóa của mã khối là E_k, trong đó k là khóa. Tương ứng, hàm giải mã là D_k.

Viết X = {X_1}|{X_2}|\cdots|{X_m} nghĩa là kết nối các khối X_i lại với nhau để tạo ra khối X.

Vector khởi tạo (initialization vector) được ký hiệu là IV.


Phương thức hoạt động đơn giản nhất là ECB. ECB mã hóa các khối bản rõ độc lập với nhau, cụ thể như sau:

Code:
Mã hóa
C_i = E_k(P_i), i=1,..,m
C = C_1|C_2|...|C_m

Giải mã
P_i = D_k(C_i), i=1,..,m
M = P_1|P_2|...|P_m


Phương thức mã hóa độc lập này có một tính chất: các khối bản rõ giống nhau sẽ cho kết quả là các khối bản mã giống nhau. Nói cách khác, so sánh giá trị của C_i và C_j với i, j bất kỳ chúng ta có thể biết được một chút "thông tin" về P_i và P_j. Đây là một tính chất không mong muốn của bất kỳ phương thức hoạt động hay hệ mã nào (bởi vì nó làm cho hệ mã không còn an toàn theo định nghĩa semantic security -13-). Điều thú vị là ECB được chọn là phương thức mặc định trong nhiều thư viện lập trình phổ biến.

Bài tập 1: Quân ta đang ở chiến trường. Mỗi ngày bộ chỉ huy sẽ gửi ra một lệnh cho biết hôm đó quân ta sẽ làm gì. Chỉ có hai lệnh: "TAN CONG" hoặc "PHONG THU". Do quân địch cũng có thể nghe lén sóng radio, nên để cho an toàn, bộ chỉ huy sử dụng ECB để mã hóa các lệnh trước khi gửi. Tất cả các lệnh đều được mã hóa bằng cùng một khóa duy nhất. Chứng minh rằng ngay trong ngày thứ hai, quân địch đã có thể đoán trước chiến thuật của quân ta.

Bài tập 2: Tìm và liệt kê các thư viện lập trình sử dụng ECB là phương thức hoạt động mặc định. Điểm thưởng: tìm trên Google Code Search các chương trình sử dụng các thư viện này và xem thử có cách nào khai thác điểm yếu của ECB trong các chương trình này hay không.

Vậy làm thế nào để phá vỡ sự độc lập giữa các khối? Làm cho chúng phụ thuộc nhau smilie. Đó cũng là ý tưởng của phương thức CBC. Tên gọi của CBC gợi ý rằng các khối bản mã sẽ được "móc nối" lại với nhau, cụ thể như sau:

Code:
Mã hóa
C_0 = IV
C_i = E_k(P_i \oplus C_{i-1}), i=1,..,m
C = C_0|C_1|C_2|\cdots|C_m

Giải mã
P_i = D_k(C_i) \oplus C_{i-1}, i=1,..,m
M = P_1|P_2|\cdots|P_m


Lưu ý rằng khi mã hóa bằng CBC, chiều dài bản mã tăng thêm một khối. Khối tăng thêm này là IV, dùng để mã hóa khối bản rõ đầu tiên. Trong CBC, IV không cần được giữ bí mật, nhưng với cùng một khóa thì IV phải độc nhất và không dự đoán được.

Bài tập 3: Giả sử bộ chỉ huy ở bài tập 1 chuyển sang sử dụng CBC. Vì thiếu thiết bị tạo số ngẫu nhiên, bộ chỉ huy quyết định chọn một IV cố định và dùng IV này trong tất cả các lần gửi lệnh. Chứng minh rằng quân địch vẫn có thể đoán trước chiến thuật của quân ta ngay trong ngày thứ hai.

CBC được sử dụng ở rất nhiều ứng dụng của mã khối, trong đó có SSL/TLS. Điểm mấu chốt trong việc sử dụng CBC chính là chọn lựa IV đảm bảo hai tiêu chí ở trên. Rất tiếc người thiết kế SSL/TLS làm sai chỗ này. Bài tập 3 gợi ý rằng, để có IV độc nhất thì nên dùng một bộ tạo số ngẫu nhiên (random number generator). Lưu ý là không phải bộ tạo số nào cũng có thể dùng trong mật mã và hầu hết các bộ tạo số ngẫu nhiên đi kèm theo các ngôn ngữ lập trình đều không an toàn. Có lẽ tôi sẽ viết một bài về đề tài này sau. Quay trở lại giá trị IV. Như vậy trong CBC, mỗi lần mã hóa, chúng ta nên chọn một IV ngẫu nhiên. Câu hỏi là: ngẫu nhiên có bao hàm không dự đoán được? Chắc chắn rồi, bởi nếu đã là ngẫu nhiên thì làm sao mà dự đoán được! Tôi nghĩ sự tồn tại của điểm yếu trong SSL/TLS, tấn công Rogaway-Dai và bây giờ là BEAST đều xuất phát từ chỗ này. Cách mà SSL/TLS chọn các IV để mã hóa các bản ghi (record) khiến các IV này ngẫu nhiên, nhưng lại dự đoán được!

Trong SSL/TLS, dữ liệu từ tầng ứng dụng được chia ra thành từng bản ghi dài không quá $latex 2^{14}$ byte, rồi các bản ghi này sẽ được mã hóa dùng CBC. Với bản ghi đầu tiên, SSL/TLS sẽ chọn một $latex IV$ hoàn toàn ngẫu nhiên từ bộ tạo số ngẫu nhiên. Từ bản ghi thứ hai trở đi, SSL/TLS sẽ chọn khối bản mã cuối cùng của bản ghi trước đó làm IV. Ví dụ như bản ghi thứ nhất có 3 khối $latex P_1, P_2, P_3$, mã hóa tạo thành 4 khối C_0, C_1, C_2, C_3, thì C_3 sẽ được chọn làm IV cho bản ghi thứ hai. Rồi khối bản mã cuối cùng của bản ghi thứ hai sẽ là $latex IV$ cho bản ghi thứ ba, v.v. Lưu ý rằng C_3 là hoàn toàn ngẫu nhiên, nhưng nếu như chúng ta biết C_3 trước khi chọn bản ghi thứ hai thì xem như IV của bản ghi thứ hai là dự đoán được. Nói cách khác, IV không dự đoán được nghĩa là chúng ta không thể biết được giá trị của IV trước khi chọn bản rõ.

Vậy chuyện gì sẽ xảy ra nếu chúng ta dự đoán được IV trước khi chọn bản rõ?

2.2 Tấn công Rogaway-Dai

Wei Dai mô tả như sau tấn công này như sau:

Wei Dai wrote:

Phil Rogaway observed that CBC mode is not secure against chosen-plaintext attack if the IV is known or can be predicted by the attacker before he choses his plaintext [1]. Similarly, CBC mode is not secure if the attacker can observe the last ciphertext block before choosing the next block of plaintext, because the last block of ciphertext essentially serves as the IV for the rest of the message.

The attack itself is very simple. Remember that in CBC mode, each plaintext block is XOR'ed with the last ciphertext block and then encrypted to produce the next ciphertext block. Suppose the attacker suspects that plaintext block P_i might be x, and wants to test whether that's the case, he would choose the next plaintext block P_j to be x XOR C_(i-1) XOR C_(j-1). If his guess is correct, then C_j = Encrypt(P_j XOR C_(j-1)) = Encrypt(P_i XOR C_(i-1)) = C_i, and so he can confirm his guess by looking at whether C_j = C_i. [...]

[1] http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt
 


Như vậy Dai chỉ ra rằng chúng ta có thể dự đoán được (giải mã!) bản rõ đã quan sát nếu chúng ta biết được IV trước khi chọn bản rõ mới trong CBC. Nếu P_i chỉ nhận 100 giá trị, thì rõ ràng chúng ta có thể giải mã được P_i sau khi thực hiện trung bình 50 bước chọn và thử P_j. Giới hạn của Rogaway-Dai nằm ở chỗ trong thực tế miền giá trị của P_i thường rất lớn. Làm sao để giảm miền giá trị của P_i?

(Phần 3: Tấn công chọn lề)

Các liên kết trong bài:

1. http://www.mail-archive.com/openssl-dev@openssl.org/msg10664.html

2. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

3. http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt

4. http://www.openssl.org/~bodo/tls-cbc.txt

5. http://eprint.iacr.org/2004/111

6. http://eprint.iacr.org/2006/136

7. http://news.cnet.com/8301-30685_3-20108633-264/researchers-to-detail-hole-in-web-encryption/

8. http://www.rsa.com/rsalabs/node.asp?id=2127

9. http://lasecwww.epfl.ch/memo/memo_ssl.shtml

10. http://scholar.google.com/scholar?q=padding+oracle&hl=en&btnG=Search&as_sdt=1%2C5&as_sdtp=on

11. http://usenix.org/events/woot10/tech/full_papers/Rizzo.pdf

12. http://www.ieee-security.org/TC/SP2011/PAPERS/2011/paper030.pdf

13. http://en.wikipedia.org/wiki/Semantic_security
http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html
[Up] [Print Copy]
[digg] [delicious] [google] [yahoo] [technorati] [reddit] [stumbleupon]
Go to: 
 Users currently in here 
1 Anonymous

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|