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ảo luận bảo mật Bảo mật dữ liệu dài lâu hơn với forward secrecy  XML
  [Discussion]   Bảo mật dữ liệu dài lâu hơn với forward secrecy 30/04/2012 13:39:16 (+0700) | #1 | 262217
[Avatar]
manthang
Journalist

[Minus]    0    [Plus]
Joined: 30/06/2008 16:36:58
Messages: 140
Offline
[Profile] [PM] [WWW]
Bài này được viết nhân việc đọc được entry sau Google Security blog:
http://googleonlinesecurity.blogspot.com/2011/11/protecting-data-for-long-term-with.html

Trên blog của Adam Langley, tác giả của entry trên, cũng có một bài nói về forward secrecy:
http://www.imperialviolet.org/2011/11/22/forwardsecret.html

Theo đó, từ năm 2010, Google đã mặc định áp dụng HTTPS cho các dịch vụ như Gmail, Search, Docs, Calendar nhằm bảo vệ tính riêng tư cho các thông tin quan trọng của người dùng. Vào cuối tháng 11/2011, Google trở thành một trong những “ông lớn” đầu tiên triển khai ”forward secrecy” cho các dịch vụ trên.

Một cách gọi khác là “perfect foward secrecy”:
http://en.wikipedia.org/wiki/Perfect_forward_secrecy

Và để hiểu tại sao việc sử dụng nó lại cần thiết đến như vậy, ta cần biết HTTPS làm việc ra sao, xem thêm:
http://en.wikipedia.org/wiki/HTTP_Secure

Về cơ bản, client và server sẽ dùng chung một session key để mã hóa các request và response mà chúng gửi cho nhau để những bên thứ 3 như ISP hay kẻ nghe lén nằm cùng mạng LAN với chúng không thể giải mã và đọc được các thông điệp đó. Mỗi server có một private key, và chỉ những ai nắm giữ private key này mới có thể giải mã được session key và từ đó đọc được thông điệp.

Hầu hết các website có hỗ trợ HTTPS đều hoạt động dưới hình thức non-forward secret (không áp dụng forward secrecy), điều này dẫn đến một rủi ro gọi là “retrospective decryption”. Tức là, attacker sẽ ghi nhận và lưu trữ lại các traffic (request, response) được mã hóa, sau đó tìm cách để biết được private key như tập kết các siêu máy tính để thực hiện bẻ khóa private key trong nhiều năm hay dò trong ổ cứng chứa private key bị giục đi chẳng hạn. Khi đó, các traffic cũ này hoàn toàn có thể bị giải mã.

May thay, với forward secrecy, ta có thể giải quyết mối đe dọa trên. Khi nó được áp dụng thì một vài “thông tin cần thiết” để giải mã traffic được tạo ra ngẫu nhiên, khác nhau cho mỗi session và chúng bị hủy bỏ (không được lưu trữ lại) sau khi session giữa client và server chấm dứt. Đặc biệt, “thông tin cần thiết” này không liên quan tới các key được lưu trữ dài lâu là public key và private key nên nếu private key có bị “compromise” thì attacker cũng không thể nào giải mã được các thông điệp được mã hóa mà hắn đã thu thập trước đó.

Có chăng là khi private key bị lộ, tính xác thực của các “thông tin cần thiết” đó không còn được đảm bảo và gây rủi ro cho các traffic mới được tạo ra sau đó. Lúc này, certificate mà cấp cho server phải sớm bị thu hồi (revoke). Tuy nhiên, forward secrecy vẫn thực sự làm tăng tính privacy cho dữ liệu cần được bảo mật dài lâu.

Vậy thì, “thông tin cần thiết” thực chất là gì, được tạo ra như thế nào và sử dụng ra sao? Bài viết sau phân tích forward secrecy làm việc trong SSL/TLS:
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html

Theo đó thì, private key chỉ được sử dụng cho mục đích authentication và signing, còn thuật toán Diffie-Hellman sẽ được dùng để trao đổi shared secret (hay session key) qua một kênh truyền thông không an toàn như Internet. Key này sau đó được dùng để mã hóa traffic giữa client và server dùng thuật toán bất đối xứng như AES, RC4. Cipher suite được thỏa thuận ở đây có thể là DHE-RSA-AES128-SHA, ECDHE-RSA-RC4-SHA, v.v…
trong đó:

+ DHE (hay EDH) = Ephemeral Diffie-Hellman

+ ECDHE = Elliptic Curve, Ephemeral Diffie-Hellman

Nên dùng stream cipher RC4 thay cho block cipher AES_CBC để ngăn chặn tấn công BEAST:
http://vnhacker.blogspot.com/2011/09/beast.html

Ngoài SSL/TLS, kỹ thuật này hiện đã được áp dụng trong các giao thức, IPSec, SSH hay Off-the-Record Messaging.
http://www.cypherpunks.ca/otr/

Do gặp phải vấn đề là tiêu tốn CPU của server nhiều hơn HTTP và HTTPS bình thường nên các hầu như các site khác đều chưa mạnh dạn triển khai forward secrecy. Nikos Mavrogiannopoulos có làm một bài test nho nhỏ ở đây:
http://nikmav.blogspot.com/2011/12/price-to-pay-for-perfect-forward.html

Để khắc phục vấn đề hiệu suất này, Google đã thực hiện các cải tiến cho thư viện mã nguồn mở OpenSSL: http://cvs.openssl.org/fileview?f=openssl/CHANGES&v=1.1481.2.56.2.57

Forward secrecy là một bước tiến quan trọng cho vấn đề web privacy nói riêng và data security nói chung. Tài liệu sau nghiên cứu khá kỹ về nó:
http://www.cs.bu.edu/~itkis/pap/forward-secure-survey.pdf

--manthang.
keep -security- in -mind-
[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|