SlowMist : Rủi ro mật mã phổ biến trong ứng dụng Blockchain

0x01 Private key Số ngẫu nhiên Bảo mật

1. Tạo số ngẫu nhiên bằng cách sử dụng Math.random của JavaScript hoặc một seed dựa trên thời gian.

• Mức độ nghiêm trọng: Cao

• Mô tả: Phương thức `Math.random()` của JavaScript là một bộ tạo số giả ngẫu nhiên (PRNG), không phù hợp cho các kịch bản bảo crypto. Việc triển khai của nó phụ thuộc vào trình duyệt hoặc công cụ JavaScript (chẳng hạn như Xorshift128+ của V8), và hạt giống cũng như thuật toán thường không thể kiểm soát và không thể dự đoán được, có khả năng dẫn đến việc các chuỗi số ngẫu nhiên được tạo ra có thể bị kẻ tấn công đoán hoặc sao chép.

• Các trường hợp sử dụng: Điều này có thể dẫn đến việc rò rỉ thông tin quan trọng, chiếm đoạt phiên hoặc gian lận trong game khi tạo khóa crypto, mã thông báo phiên, mã thông báo CSRF hoặc các sự kiện ngẫu nhiên trong game.

• Khuyến nghị : Ưu tiên sử dụng crypto.getRandomValues() (API mã hóa trên web) để tạo các số ngẫu nhiên an toàn crypto, phù hợp cho các trường hợp nhạy cảm như khóa và mã thông báo.

2. Tạo private key bằng phương pháp tạo số ngẫu nhiên không an toàn của Java.

• Mức độ nghiêm trọng : Cao

• Mô tả: Java's java.util.Random hoặc java.util.concurrent.ThreadLocalRandom là các bộ tạo số ngẫu nhiên giả (PRNG) không an toàn crypto. Các hạt giống và thuật toán của chúng (chẳng hạn như bộ tạo đồng dư tuyến tính) có thể dự đoán được và thiếu entropy. Nếu phương pháp này được sử dụng để tạo private key crypto (như RSA, ECDSA), các khóa được tạo ra có thể dự đoán được và dễ dàng bị kẻ tấn công suy ra hoặc sao chép.

• Trường hợp sử dụng: Trong các ứng dụng web dựa trên Java, các khóa được tạo bằng Random có ​​thể bị kẻ tấn công lợi dụng để phá vỡ các phiên TLS hoặc ngụy tạo mã thông báo JWT.

• Khuyến nghị: Nên sử dụng java.security.SecureRandom thay thế. Đây là trình tạo số ngẫu nhiên được thiết kế cho các kịch bản crypto, cung cấp đầu ra có độ entropy cao, phù hợp để tạo private key. Hoặc, ưu tiên sử dụng các thư viện hoặc framework tiêu chuẩn (như KeyPairGenerator hoặc KeyFactory) để tạo khóa.

1. Trên một số phiên bản Android, SecureRandom không khởi tạo đúng cách.

• Mức độ nghiêm trọng: Cao

• Mô tả: Trong một số phiên bản Android (đặc biệt là các phiên bản cũ hơn, chẳng hạn như 4.1-4.3), java.security.SecureRandom không được khởi tạo đúng cách, dẫn đến lượng entropy không đủ cho các số ngẫu nhiên được tạo ra. Điều này thường là do vùng chứa entropy của hệ thống không được lấp đầy đủ (chẳng hạn như /dev/urandom) hoặc do lỗi trong quá trình triển khai SecureRandom, khiến chuỗi số ngẫu nhiên được tạo ra có tính dự đoán cao, làm giảm đáng kể tính bảo mật khi được sử dụng để tạo private key.

• Trường hợp sử dụng: Trên các thiết bị Android bị ảnh hưởng, private key Bitcoin được tạo bằng SecureRandom có ​​thể bị xâm phạm, dẫn đến việc đánh cắp tiền.

• Khuyến nghị: Trước khi gọi SecureRandom, hãy gọi rõ ràng SecureRandom.setSeed() và kết hợp nó với các nguồn có độ ngẫu nhiên cao (chẳng hạn như dữ liệu đầu vào của người dùng hoặc dữ liệu cảm biến phần cứng) để tăng cường tính ngẫu nhiên.

1. Dung lượng lưu trữ các số ngẫu nhiên trong quá trình tạo private key quá nhỏ.

• Mức độ nghiêm trọng: Cao

• Mô tả: Nếu sử dụng kiểu dữ liệu biến có dung lượng lưu trữ quá nhỏ (chẳng hạn như số nguyên 32 bit) để lưu trữ các số ngẫu nhiên trong quá trình tạo private key, điều này sẽ hạn chế phạm vi và độ phức tạp của các số ngẫu nhiên, dẫn đến độ mạnh của private key được tạo ra không đủ.

• Các trường hợp sử dụng: Kẻ tấn công có thể khai thác phạm vi giới hạn của các số ngẫu nhiên để nhanh chóng đoán được private key thông qua các cuộc tấn công vét cạn hoặc các cuộc tấn công tính toán trước (như bảng cầu vồng). Ví dụ, trong trường hợp công cụ Profanity, kẻ tấn công đã thành công trong việc bẻ khóa nhiều ví Ethereum và đánh cắp lượng lớn bằng cách phân tích các mẫu địa chỉ được tạo ra.

• Khuyến nghị: Sử dụng kiểu dữ liệu biến đủ lớn (ví dụ: 256 bit trở lên) để lưu trữ các số ngẫu nhiên nhằm hỗ trợ toàn bộ không gian khóa (ví dụ: phạm vi 2^256 của đường cong secp256k1).

1. Lỗ hổng Entropy yếu trong Libbitcoin Mersenne Twister

• Mức độ nghiêm trọng: Cao

• Mô tả: Lệnh `bx Seed trong Libbitcoin Explorer (phiên bản 3.0.0 đến 3.6.0) sử dụng bộ tạo số giả ngẫu nhiên (PRNG) Mersenne Twister (MT19937) để tạo ra một seed ví, được khởi tạo chỉ với thời gian hệ thống 32 bit (high_resolution_clock). Điều này dẫn đến không gian entropy bị giới hạn ở 2^32 (khoảng 4,3 tỷ) giá trị có thể, thấp hơn nhiều so với yêu cầu entropy an toàn 128 bit hoặc 256 bit. Kẻ tấn công có thể tái tạo seed thông qua các cuộc tấn công vét cạn, từ đó suy ra private key và gây nguy hiểm cho tiền của người dùng. Lỗ hổng này được gọi là "Milk Sad" vì cụm từ seed đầu tiên được tạo ra bắt đầu bằng "milk sad".

• Trường hợp sử dụng : `get_clock_seed()` trả về dấu thời gian hệ thống 32 bit (uint32_t), có thể được sử dụng làm hạt giống cho thuật toán Mersenne Twister. Mặc dù `std::mt19937` tạo ra đầu ra có vẻ ngẫu nhiên, nhưng entropy của nó bị giới hạn bởi hạt giống 32 bit, khiến nó không thể cung cấp mức độ bảo mật 128 bit hoặc cao hơn. Khi điền đầu ra bằng `pseudo_random_fill`, mở rộng lên 256 bit chỉ đơn thuần là mở rộng giả ngẫu nhiên và không làm tăng entropy thực tế.

• Khuyến nghị: Thay thế thuật toán Mersenne Twister bằng một bộ tạo số ngẫu nhiên an toàn crypto(chẳng hạn như /dev/urandom, std::random_device của C++ với nguồn có độ entropy cao, hoặc RAND_bytes của OpenSSL).

6. Rủi ro bảo mật của bộ tạo số ngẫu nhiên OpenSSL

• Mức độ nghiêm trọng: Cao

• Mô tả: Bộ tạo số ngẫu nhiên RAND_pseudo_bytes() của thư viện mã hóa OpenSSL được sử dụng để đưa `num` byte giả ngẫu nhiên vào `buf`, nhưng nó có một lỗ hổng bảo mật. Chuỗi byte giả ngẫu nhiên được tạo ra bởi RAND_pseudo_bytes() là duy nhất nếu độ dài của nó đủ dài, nhưng không nhất thiết là không thể dự đoán được. Chúng có thể được sử dụng cho các mục đích crypto và cho các mục đích cụ thể trong một số giao thức crypto, nhưng nói chung không được sử dụng để tạo khóa, v.v.

• Ví dụ về lỗ hổng: Rò rỉ khóa có độ phức tạp thấp (LESLI), trong đó kẻ tấn công có thể khôi phục giá trị mã PIN gốc bằng cách lấy được nonce và tấn công vét cạn tất cả các mã PIN và trạng thái RNG có thể có.

   

• Khuyến nghị: Tránh sử dụng RAND_pseudo_bytes, hãy thay thế hoàn toàn bằng RAND_bytes và kiểm tra giá trị trả về của nó.

   

0x02 Bảo mật ECDSA

1. Vấn đề cửa hậu secp256r1

• Mức độ nghiêm trọng: Trung bình

• Mô tả: secp256r1 (còn được gọi là NIST P-256) là một thuật toán mã hóa đường cong elliptic được sử dụng rộng rãi, nhưng có những lo ngại về các lỗ hổng tiềm ẩn trong quá trình tạo tham số của nó. Trong quá trình chuẩn hóa, các tham số được cung cấp bởi NSA, thiếu tính minh bạch trong quá trình tạo ra chúng. Điều này có thể được cố ý thiết kế để chứa các điểm yếu, cho phép các kẻ tấn công cụ thể (như NSA) khai thác các mối quan hệ toán học ẩn để giải mã dữ liệu hoặc ngụy tạo chữ ký.

• Các trường hợp sử dụng: Kẻ tấn công có thể khai thác các cửa hậu (nếu có) để nhanh chóng tính toán private key hoặc dự đoán đầu ra của bộ tạo số ngẫu nhiên bằng cách tận dụng các thuộc tính toán học của các tham số đã biết, từ đó phá vỡ các liên lạc crypto, ngụy tạo chữ ký số hoặc đánh cắp dữ liệu nhạy cảm trong các hệ thống crypto dựa trên secp256r1 (như TLS, Bitcoin, SSH).

• Khuyến nghị: Hãy cân nhắc chuyển sang sử dụng các đường cong có tham số được tạo một cách minh bạch, chẳng hạn như Ed25519 hoặc Secp256k1, để giảm rủi ro tấn công bằng cửa hậu.

2. Tính ngẫu nhiên yếu của giá trị k trong secp256k1 dẫn đến rò rỉ private key.

• Mức độ nghiêm trọng: Cao

• Mô tả: Trong quy trình ký ECDSA của đường cong secp256k1, một số ngẫu nhiên k (nonce) là cần thiết cho chữ ký. Nếu giá trị của k được tạo ra bởi một bộ tạo số ngẫu nhiên yếu (ví dụ: nguồn có độ entropy thấp, bộ tạo số ngẫu nhiên giả không an toàn hoặc một hạt giống có thể dự đoán được), kẻ tấn công có thể suy ra giá trị của k bằng cách phân tích dữ liệu chữ ký và sau đó tính toán trực tiếp private key bằng cách sử dụng các thuộc tính toán học của ECDSA. Lỗ hổng này thường bắt nguồn từ việc sử dụng các bộ tạo số ngẫu nhiên không an toàn (như rand(), Math.random()) hoặc độ entropy hoàn cảnh không đủ (như máy ảo hoặc thiết bị nhúng).

• Trường hợp sử dụng: Kẻ tấn công có thể tái tạo giá trị của k và suy ra private key bằng cách thu thập một lượng nhỏ dữ liệu chữ ký (ví dụ: giá trị r và s) và kết hợp nó với tính dự đoán được của các số ngẫu nhiên yếu. Trong các kịch bản blockchain(như Bitcoin và Ethereum), điều này có thể dẫn đến việc lộ private key của ví và đánh cắp tiền. Ví dụ, nếu giá trị k được tạo dựa trên dấu thời gian hoặc một hạt giống cố định, kẻ tấn công có thể nhanh chóng khôi phục private key thông qua các cuộc tấn công vét cạn hoặc phân tích mẫu. Các vấn đề tương tự đã xảy ra trong các triển khai ví tiền crypto ban đầu, bị xâm phạm do sử dụng các nguồn ngẫu nhiên yếu để tạo ra giá trị k.

• Khuyến nghị: Sử dụng phương pháp tạo giá trị k xác định (RFC 6979) để tạo ra một giá trị k duy nhất dựa trên private key và hàm băm của thông điệp, tránh phụ thuộc vào chất lượng của bộ tạo số ngẫu nhiên.

3. Việc tái sử dụng giá trị k trong secp256k1 dẫn đến rò rỉ private key .

• Mức độ nghiêm trọng: Cao

• Mô tả: Khi sử dụng chữ ký ECDSA trên đường cong elip secp256k1 (được sử dụng rộng rãi trong crypto như Bitcoin ), nếu lần chữ ký sử dụng cùng một số ngẫu nhiên k (nonce), giá trị của r trong các chữ ký sẽ giống hệt nhau. Kẻ tấn công có thể suy ra private key bằng cách phân tích hai tập hợp chữ ký này (r, s1) và (r, s2) và các hàm băm thông điệp tương ứng h1 và h2. Lỗ hổng này bắt nguồn từ cấu trúc toán học của các phương trình chữ ký ECDSA; việc tái sử dụng k cho phép kẻ tấn công xây dựng một hệ phương trình và giải trực tiếp để tìm ra private key d.

• Khuyến nghị: Tuân theo RFC 6979 để tạo ra giá trị k xác định nhưng không thể dự đoán được dựa trên private key và hàm băm của thông điệp nhằm ngăn chặn việc sử dụng lại.

4. Tính dễ uốn nắn của các giá trị chữ ký ECDSA

• Mức độ nghiêm trọng: Trung bình

• Mô tả: Giá trị chữ ký ECDSA (Thuật toán chữ ký số đường cong elip) (r, s) thể hiện tính dễ thay đổi, nghĩa là với một chữ ký hợp lệ (r, s), một chữ ký hợp lệ tương đương khác (r, -s mod n) có thể được tạo ra, trong đó n là bậc của đường cong elip. Thuộc tính toán học này xuất phát từ tính đối xứng modulo của quá trình xác minh chữ ký ECDSA. Nếu một chữ ký không được chuẩn hóa được triển khai (ví dụ: buộc sử dụng "giá trị s thấp"), kẻ tấn công có thể sửa đổi chữ ký mà không ảnh hưởng đến tính hợp lệ của nó, có khả năng vượt qua các cơ chế xác minh chữ ký hoặc vi phạm các yêu cầu về tính duy nhất của một số giao thức.

• Các trường hợp sử dụng: Kẻ tấn công có thể khai thác tính dễ bị thay đổi của chữ ký để tạo ra các vấn đề trong blockchain(như Bitcoin và Ethereum) hoặc các giao thức. Ví dụ, trong các giao dịch Bitcoin, kẻ tấn công có thể sửa đổi giá trị `s` của chữ ký giao dịch để tạo ra một chữ ký mới, thay đổi ID giao dịch (txid), khiến giao dịch bị từ chối hoặc gây ra rủi ro chi tiêu kép. Hơn nữa, trong một số hợp đồng thông minh hoặc giao thức đa chữ ký, chữ ký không được chuẩn hóa có thể được sử dụng để bỏ qua logic xác minh, dẫn đến tổn thất tài chính hoặc lỗi giao thức. Năm 2013, mạng Bitcoin đã trải qua một cuộc tấn công làm thay đổi giao dịch do tính dễ bị thay đổi của chữ ký, ảnh hưởng đến sàn giao dịch như Mt. Gox.

• Khuyến nghị: Bắt buộc sử dụng "giá trị s thấp" (s ≤ n/2), tuân theo tiêu chuẩn RFC 6979 hoặc BIP-66 (được cộng đồng Bitcoin thông qua) và từ chối các chữ ký không chính tắc để loại bỏ khả năng làm giả.

5. Chữ ký ECDSA và chữ ký Schnorr sử dụng cùng một số ngẫu nhiên k, dẫn đến rò rỉ private key.

• Mức độ nghiêm trọng: Cao

• Mô tả: Trong thuật toán chữ ký số đường cong Elliptic (ECDSA) và chữ ký Schnorr, nếu cùng một số ngẫu nhiên k (nonce) được sử dụng khi tạo chữ ký, kẻ tấn công có thể suy ra private key bằng cách phân tích chữ ký. Lỗ hổng này xuất phát từ sự tương đồng trong cấu trúc toán học của hai lược đồ chữ ký, cho phép suy ra private key từ phương trình chữ ký đã biết. Cho dù ký lần trong cùng một hệ thống hay tái sử dụng k trên các thuật toán chữ ký khác nhau, private key sẽ bị lộ hoàn toàn, cho phép kẻ tấn công ngụy tạo chữ ký hoặc kiểm soát các tài khoản liên quan.

• Khuyến nghị: RFC6979 cho phép tham số đầu vào bao gồm "dữ liệu bổ sung". Khi tạo k, thông tin thuật toán chữ ký có thể được điền vào trường này, do đó cho phép tái sử dụng k một cách an toàn ở cấp độ thuật toán.

6. ECDSA có thể ngụy tạo giá trị chữ ký khi nó không yêu cầu thông điệp m tương ứng với giá trị chữ ký đó.

• Mức độ nghiêm trọng: Thấp

• Mô tả: Khi xác thực chữ ký ECDSA, nếu quy trình xác thực chỉ yêu cầu giá trị băm của thông điệp thay vì chính thông điệp gốc, kẻ tấn công có thể tạo ra một chữ ký ngụy tạo vượt qua quá trình xác thực dựa trên một chữ ký hợp lệ đã biết, mà không cần biết private key . Lỗ hổng này khai thác các thuộc tính toán học của cơ chế xác thực ECDSA, cho phép kẻ tấn công lựa chọn các tổ hợp giá trị cụ thể để tạo ra chữ ký ngụy tạo mà không cần biết thông điệp gốc hoặc private key tương ứng.

• Khuyến nghị: Khi xác minh chữ ký, cần phải có thông điệp gốc m, chứ không chỉ giá trị băm.

7. Lỗ hổng tấn công kênh phụ Nonce trong chữ ký ECDSA

• Mức độ nghiêm trọng: Cao

• Mô tả: LadderLeak là một lỗ hổng kênh phụ trong các triển khai ECDSA. Kẻ tấn công có thể lấy được bit quan trọng nhất của nonce được sử dụng trong quá trình ký thông qua phân tích thời gian được lưu trong bộ nhớ cache, nhưng xác suất rò rỉ nhỏ hơn 100% (tức là "ít hơn 1 bit" thông tin). Lỗ hổng này tồn tại trong các nhánh OpenSSL 1.0.2 và 1.1.0, cũng như bộ công cụ RELIC phiên bản 0.4.0, đặc biệt ảnh hưởng đến các triển khai ECDSA dựa trên các đường cong section163r1 và NIST P-192. Lỗ hổng bắt nguồn từ sự chênh lệch thời gian nhỏ do xử lý tọa độ không chính xác trong việc triển khai thuật toán hình thang Montgomery. Kẻ tấn công có thể quan sát sự chênh lệch thời gian này và sử dụng phương pháp thống kê suy đoán bit quan trọng nhất của nonce k. Mặc dù tỷ lệ rò rỉ này thấp hơn 100% (ví dụ: 99% đối với P-192 và 97,3% đối với phần 163r1), kẻ tấn công vẫn có thể khôi phục hoàn toàn private key bằng cách thu thập đủ số lượng chữ ký bằng phương pháp phân tích Fourier Bleichenbacher cải tiến.

• Ví dụ về lỗ hổng: Các lỗ hổng trong triển khai OpenSSL xuất hiện ở cả trường hợp đường cong nhị phân (ví dụ: sect163r1) và trường hợp đường cong số nguyên tố (ví dụ: NIST P-192). 

  
  

  1. Lỗ hổng về khả năng mở rộng trong quá trình xác thực chữ ký BLS Filecoin

  
  

  • Mức độ nghiêm trọng: Cao

  
  

  • Mô tả: Một lỗ hổng về khả năng mở rộng đã được phát hiện trong cơ chế xác minh chữ ký BLS của triển khai Lotus của Filecoin. Chữ ký BLS có thể được biểu diễn dưới hai dạng khác nhau : Filecoin và được nén. Cả hai dạng đều có thể được xác minh thành công bằng phương pháp`VerifyCompressed` của thư viện BLST. Tuy nhiên, logic xác minh khối của Lotus sử dụng CID Block Header , bao gồm cả chữ ký, để xác định tính duy nhất của khối. Điều này dẫn đến vấn đề bảo mật sau: cùng một khối sử dụng hai dạng chữ ký BLS khác nhau sẽ được coi là hai khối khác nhau vì CID của chúng khác nhau. Kẻ tấn công có thể khai thác lỗ hổng này bằng cách gửi các khối chứa cùng nội dung nhưng với các định dạng chữ ký khác nhau, bỏ qua việc phát hiện khối trùng lặp, có khả năng dẫn đến fork blockchain , Tấn công chi tiêu hai lần hoặc lỗi đồng thuận.

  
  

  • Khuyến nghị: Trước khi xác minh chữ ký, hãy chuyển đổi tất cả chữ ký sang định dạng thống nhất (sử dụng phương pháp tuần tự hóa hoặc nén).

  
  

  2. Các lỗ hổng liên quan đến giá trị bằng không và các cuộc tấn công "chia tách giá trị bằng không" trong thư viện BLS

  
  

  • Mức độ nghiêm trọng: Cao

  
  

  • Mô tả: Các nhà nghiên cứu đã phát hiện ra sê-ri lỗ hổng bảo mật nghiêm trọng liên quan đến việc xử lý giá trị 0 trong bốn thư viện crypto BLS (Boneh-Lynn-Shacham) chính thống và bản dự thảo tiêu chuẩn BLS, được gọi chung là các cuộc tấn công "tách số 0". Những lỗ hổng này bắt nguồn từ các sai sót trong việc xử lý giá trị đặc biệt "0" trong các thuật toán crypto, có khả năng dẫn đến việc bỏ qua xác minh chữ ký, khôi phục private key, tấn công từ chối dịch vụ và các vấn đề bảo mật nghiêm trọng khác. Đặc biệt, báo cáo trên GitHub cũng đề cập đến các lỗ hổng liên quan đến giá trị 0 khác, bao gồm: trong thư viện supranational/blst, chữ ký có độ dài bằng 0 hoặc thông điệp có độ dài bằng 0 gây ra sự cố chương trình; và trong các phép toán modulo p, việc xử lý nghịch đảo (0) mod p = 0, nhưng nghịch đảo (p) mod p = 1 là không chính xác. Các lược đồ chữ ký BLS được sử dụng rộng rãi trong blockchain và các hệ thống phân tán do các đặc tính tổng hợp độc đáo của chúng, và những lỗ hổng này có thể gây ra những hậu quả bảo mật đáng kể đối với các hệ thống lớn dựa vào các thư viện này.

  
  

  • Ví dụ về các lỗ hổng: Theo các tài liệu nghiên cứu, các cuộc tấn công "phân tách giá trị bằng không" chủ yếu bao gồm bỏ qua xác minh chữ ký bằng không, tấn công khóa công khai bằng không, các lỗ hổng gây sập thư viện, các vấn đề về giá trị bằng không trong các phép toán modulo và thao tác giá trị bằng không trong chữ ký tổng hợp.
    

  • Khuyến nghị: Xác định rõ ràng và thực hiện nhất quán các chiến lược xử lý giá trị bằng không (đầu vào có độ dài bằng không, điểm bằng không, số vô hướng bằng không, v.v.).

  
  

  3. Lỗ hổng tấn công Key giả mạo trong hệ thống chữ ký đa chữ ký BLS

  
  

  • Mức độ nghiêm trọng: Cao

  
  

  • Mô tả: Trong lược đồ chữ ký BLS, việc tổng hợp khóa công khai và chữ ký được thực hiện đơn giản bằng phép cộng. Kẻ tấn công có thể tạo ra " Key giả" bằng cách đặt khóa bí mật bằng 0 và tính toán nghịch đảo cộng của khóa trung thực để vô hiệu hóa đóng góp của những người tham gia trung thực.

  
  

  • Khuyến nghị: Thực hiện xác minh nghiêm ngặt cơ chế Chứng minh quyền sở hữu (Proof-of-Possession - PoP) để tránh dựa vào phép cộng tổng đơn giản; xem xét sử dụng phép cộng tổng phi tuyến tính hoặc thêm yếu tố ngẫu nhiên.

     

  0x06 Bảo mật RSA

   

  
  

  1. Tấn công sinh nhật va chạm băm

  
  

  • Mức độ nghiêm trọng: Cao

  
  

  • Mô tả: Cuộc tấn công sinh nhật băm dựa trên "nghịch lý sinh nhật" trong lý thuyết xác suất. Nguyên tắc này có thể được sử dụng để giảm đáng kể độ phức tạp tính toán cần thiết để tìm ra các xung đột băm. Đối với một hàm băm n bit, về mặt lý thuyết cần 2^n lần để tìm ra một xung đột cụ thể, nhưng bằng cách sử dụng cuộc tấn công sinh nhật, chỉ cần khoảng 2^(n/2) lần để tìm ra rằng bất kỳ hai đầu vào nào cũng tạo ra cùng một giá trị băm với xác suất 50%.

  
  

  • Ví dụ về lỗ hổng: Giả sử hàm băm MD5 (đầu ra 128 bit) được sử dụng, kẻ tấn công có thể tìm thấy sự xung đột bằng cách tạo ra khoảng 2^64 thông điệp biến thể. Ví dụ, kẻ tấn công tạo ra hai tệp hợp đồng khác nhau A và B (A hợp lệ, B bị giả mạo) sao cho MD5(A) = MD5(B). Nếu hệ thống sử dụng MD5 để xác minh chữ ký, kẻ tấn công có thể sử dụng chữ ký của A ngụy tạo B, dẫn đến các tình huống như xung đột MD5 được sử dụng để tạo chứng chỉ giả trong cuộc tấn công Flaming năm 2004, hoặc phần mềm độc hại Flame năm 2012 khai thác xung đột để vượt qua xác minh Windows Update.

  
  

  • Khuyến nghị: Sử dụng các thuật toán băm hiện đại có khả năng chống va chạm mạnh, chẳng hạn như SHA-256, SHA-3 hoặc BLAKE2, và tránh sử dụng các thuật toán như MD5 và SHA-1, vốn đã được chứng minh là không an toàn.

  
  

  2. Tấn công mở rộng độ dài hàm băm

  
  

  • Mức độ nghiêm trọng: Cao

  
  

  • Mô tả: Tấn công mở rộng độ dài là một cuộc tấn công mật mã nhắm vào các hàm băm sử dụng cấu trúc Merkle-Damgård (như sê-ri MD5, SHA-1 và SHA-2). Kẻ tấn công khai thác hoạt động bên trong của các hàm băm này để tính toán giá trị của H(thông điệp||đệm||phần mở rộng) chỉ bằng cách biết H(thông điệp) và độ dài của nó, mà không cần biết chính thông điệp đó, trong đó phần mở rộng là dữ liệu tùy ý do kẻ tấn công lựa chọn. Cuộc tấn công này khả thi vì các thuật toán băm Merkle-Damgård chia đầu vào thành dữ liệu có độ dài cố định, và giá trị băm của mỗi khối phụ thuộc vào trạng thái băm của khối trước đó. Điều này có nghĩa là kẻ tấn công có thể tiếp tục tính toán từ một trạng thái băm đã biết, thêm nhiều dữ liệu hơn mà không cần biết dữ liệu gốc đã tạo ra trạng thái đó. Loại lỗ hổng này đặc biệt nguy hiểm trong các ứng dụng web, xác minh API, hệ thống xác thực danh tính và ứng dụng blockchain, đặc biệt khi hệ thống sử dụng các mẫu xác minh đơn giản như H(bí mật||thông điệp).

  
  

  • Khuyến nghị: Sử dụng các thuật toán băm hiện đại không có cấu trúc Merkle-Damgård, chẳng hạn như SHA-3 và BLAKE2, vì các thuật toán này tự nhiên miễn nhiễm với các cuộc tấn công mở rộng độ dài.

     

  Bảo mật AES 0x08

   

  
  

  1. Biến đổi Fiat-Shamir yếu

  
  

  • Mức độ nghiêm trọng: Cao

  
  

  • Mô tả: Phép biến đổi Fiat-Shamir là một phương pháp quan trọng để chuyển đổi các giao thức Bằng chứng không tri thức tương tác thành các giao thức chứng minh không tương tác. Nó thay thế các thử thách ngẫu nhiên trong bên chứng minh và bên xác minh bằng đầu ra của một hàm băm. Lỗ hổng Frozen Heart đề cập đến việc sử dụng phép biến đổi "Fiat-Shamir yếu" trong quá trình triển khai phép biến đổi Fiat-Shamir. Điều này có nghĩa là chỉ một phần thông điệp của bên chứng minh được băm, mà không băm thông tin công khai (chẳng hạn như tham số, đầu vào công khai, v.v.). Điều này cho phép kẻ tấn công ngụy tạo bằng chứng và đánh lừa bên xác minh bằng cách sử dụng khóa công khai A được tính toán trước mà không cần biết giá trị bí mật. Lỗ hổng này ảnh hưởng đến một số hệ thống Bằng chứng không tri thức phổ biến, bao gồm Bulletproofs, Plonk, Spartan và VDF của Wesolowski.

  
  

  • Khuyến nghị: Hãy đảm bảo rằng tất cả dữ liệu đầu vào chung đều được đưa vào quy trình tạo số ngẫu nhiên trong quá trình triển khai phép biến đổi Fiat-Shamir.

  
  

  2. Các lỗ hổng bảo mật Paillier Key trong GG18 và GG20

  
  

  • Mức độ nghiêm trọng: Cao

  
  

  • Mô tả lỗ hổng: Lỗ hổng này tồn tại trong đặc tả của hai giao thức Tính toán Bên long(MPC) được sử dụng rộng rãi, GG18 và GG20, ảnh hưởng đến hơn 10 ví và thư viện (bao gồm cả Dịch vụ Binance). Nguyên nhân gốc rễ của lỗ hổng nằm ở việc triển khai giao thức không kiểm tra xem môđun Paillier N của kẻ tấn công có chứa các thừa số nhỏ hay là số nguyên tố kép hay không. Kẻ tấn công có thể khai thác lỗ hổng này để tương tác với người ký trong giao thức MPC, đánh cắp các phân mảnh bí mật của họ và cuối cùng lấy được khóa bí mật chính, từ đó giành quyền rút hoàn toàn private key và đánh cắp tất cả tiền trong ví crypto .

  
  

  • Khuyến nghị: Hãy đảm bảo rằng khóa công khai Paillier của người ký được kiểm tra xem có chứa các thừa số nguyên tố nhỏ hay không để ngăn chặn kẻ tấn công sử dụng các môđun độc hại chứa các thừa số nhỏ (chẳng hạn như các số nguyên tố có kích thước 2^20).

     

  Tóm tắt

  Đội ngũ bảo mật SlowMist mã nguồn mở " Rủi ro mật mã phổ biến trong ứng dụng Blockchain ", nhằm mục đích hệ thống hóa việc phát hiện rủi ro bảo mật cao ẩn giấu trong các khía cạnh cốt lõi như tạo private key, chữ ký số, hàm băm và crypto đối xứng. Các dự án Web3 có thể tham khảo bài viết này để phân tích các nguyên tắc, kịch bản khai thác và đề xuất khắc phục các lỗ hổng khác nhau, từ đó hiểu sâu hơn về bảo mật mật mã, tránh các lỗi thường gặp khi triển khai và do đó bảo vệ tài sản của dự án và người dùng một cách hiệu quả hơn.