public key (RSA/ECDSA) ko xài để mã hóa session key nha em :V Trước đây có xài nhưng giờ khuyến cáo ko xài nữa. Để trao đổi session key người ta xài https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange. Để xác minh danh tính người ta mới xài RSA/ECDSA.
Cái tên protocol nói lên tất cả :V Ví dụ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
Cơ chế hoạt động của bước handshake trong tls:
- Client A gửi 1 số ngẫu nhiên x và các bộ mã hóa mà A chấp nhận (ví dụ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA) tới server B
- Server B gửi lại {1 số ngẫu nhiên y, 1 chứng minh thư (certificate), và chọn 1 bộ mã hóa} cho client A.
- Client A nhận được chứng minh thư, kiếm tra chứng minh thư (cmt) này valid: ktra con dấu trên cmt đó có của các cơ quan thẩm quyền ko, nếu phải thì cmt này là thật, ngoài ra còn phải kiểm tra xem cmt này hết hạn chưa. Nếu cmt này valid, A sẽ gửi lại cho B 1 số ngẫu nhiên z nữa, được mã hóa bằng public key ở trong chứng minh thư của B, tạm gọi là pk(z), để xác nhận B chính là chủ nhân của chứng minh thư này.
- Server B nhận được bí mật pk(z), nếu B có secret key thì sẽ giải mã được ra z = sk(pk(z)). Sau đó B tính session key = f(x, Y, z), với f là hàm trao đổi session key, được ghi tên trong bộ mã hóa, ví dụ ở đây là ECDHE (cụ thể hơn session key này sẽ được chia thành nhiều keys khác nhau nữa :V)
- A đồng thời cũng tính ra được session key = f(X, y, z)
- A và B sẽ gửi cho nhau 1 thông điệp thông báo kết thúc, mã hóa bằng session key. Nếu cả 2 có cùng 1 session key thì sẽ giải mã được thông điệp, xác nhận bắt tay thành công
trong đó số X được A tạo ngẫu nhiên, rồi dùng 1 hàm g() để tạo ra số x = g(X) truyền cho B. B cũng làm tương tự, tạo số ngẫu nhiên Y, rồi gửi cho A y = g(Y). g là 1 hàm “đặc biệt”, key tạo từ cặp số (g(X), Y) và (X, g(Y)) sẽ có kết quả tương tự. Nếu 1 người nhìn trộm được được số x (là g(X)) và số y là g(Y)), vẫn ko thể tạo ra key từ g(X), g(Y) được, mà phải biết 1 trong 2 số X và Y, mà 2 số này đều được giữ bí mật.
lưu ý session key vẫn tạo từ 1 phần từ z mã hóa bằng public key của RSA/ECDSA nên nhiều người tưởng là trao đổi key bằng RSA, thực tế ko phải, z chỉ được dùng để xác nhận B có secret key ứng với public key trong chứng minh thư kia thôi :V Chủ yếu DHE/ECDHE với x, y là đã có thể trao đổi được session key rồi, nhưng 1 mình DHE ko thôi thì ko đủ vì ko xác nhận được danh tính của B. Nếu ko xác nhận được danh tính của B, rất có thể sẽ có 1 người đứng giữa giả làm B, trao đổi A <==> E <==> B, A ko biết được cứ ngỡ là mình đang trao đổi với B, nhưng đang bị E nghe lén toàn bộ :V Vì vậy phải cần xác nhận danh tính bằng cái chứng minh thư kia :V
nếu 1 người bắt được chứng minh thư của B thì họ chả làm được cái quái gì cả :V Vì chứng minh thư đó là public, ai cũng có thể lấy được. Chỉ khi họ chôm được secret key của B thì mới mạo danh là B được.
nếu chứng minh thư của B ko có con dấu xác nhận của cơ quan thẩm quyền, ai cũng có thể mạo danh là B, ko cần chôm cái chứng minh thư của B làm gì. Ví dụ ngoài đời thật :V nếu ko có pháp luật trừng trị làm giả cmnd thì nhiều người sẽ tự in cmnd rồi mạo danh làm người khác. Nhưng pháp luật chỉ để trừng trị chứ ko có ngăn chặn triệt để, bằng chứng là ai cũng có thể tự in cmnd mạo danh người khác, mạo danh lừa xong rồi pháp luật mới trừng trị :V Với toán học thì khác, với cryptography thì khác :V Crypto có thể ngăn chặn “triệt để” người khác làm giả cmnd bằng chữ ký điện tử :V
chữ ký điện tử cũng là mã hóa từ public/secret key, thay vì xài pk mã hóa thì ở đây đi xài sk để mã hóa. Public key của B sẽ được mã hóa cùng với chứng minh thư của B bằng secret key của cơ quan thẩm quyền C thành 1 số gọi là chữ ký điện tử (digital signature) dsB = skC(hash(certB)). A sẽ lưu trữ các public key của các cơ quan thẩm quyền khác nhau. Khi nhận được chứng minh thư “của B” (dấu ngoặc kép nghĩa là chưa biết rõ, nó bảo của nó nhưng chưa xác thực :V). A sẽ lấy ra chữ ký điện tử dsB, lấy ra thông tin của cơ quan thẩm quyền C ghi trong chứng minh thư, rồi tính h’ = pkC(dsB). Tiếp theo A lấy ra thông tin hàm hash, tính h = hash(certB). Nếu 2 kết quả hash giống nhau h = h’ thì đây đúng là chứng minh thư của B. À ngoài ra A còn phải kiếm tra xem chứng minh thư này có hết đát hay ko nữa :V Nếu hết đát thì cmt này vứt :V
1 cái lưu ý nữa là A phải lưu nhiều public key của nhiều cơ quan thẩm quyền khác nhau :V Các cơ quan thẩm quyền này cũng sẽ có chứng minh thư của họ, và được các cơ quan thẩm quyền cao hơn nữa xác nhận. Và A cũng phải lưu các public key của các cơ quan thẩm quyền cao hơn này :V Ở cơ quan thẩm quyền cao nhất, ko ai có thể xác nhận được danh tính của cơ quan này mà họ tự xác nhận họ là… họ (self-signed) :V :V :V nghĩa là sau cùng A cũng phải tin tưởng 1 cơ quan nào đó :V Nhưng cơ quan này rất có danh tiếng nên có lẽ ko sao :V
ví dụ chứng minh thư của daynhauhoc :V
được COMODO ECC server CA 2 ký :V
COMODO ECC CA 2 lại được COMODO ECC CA ký
COMODO ECC CA lại được ông cao hơn ký nữa
và ông cao nhất tự ký :V
nhắc tới cái chain này để biết là mình luôn phải tin tưởng 1 ai đó, và cũng phải đề phòng khi “nhận” thêm 1 root certificate(chứng minh thư tự ký) nào đó, vì có vụ tấn công thông qua root cert rồi: https://en.wikipedia.org/wiki/Superfish#Lenovo_security_incident Tháng 12/2014 cách đây 5 năm :V
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?