Bây giờ chúng tôi sẽ đánh giá mức độ thiệt hại mà kẻ tấn công có thể gây ra bằng cách sử dụng phương pháp luận được mô tả trước đây để làm rò rỉ khóa và
người giám sát các giao dịch của blockchain. Nghĩa là, chúng tôi sử dụng bản sao blockchain của mình để tạo một chuỗi chữ ký có thứ tự [(Δ1, , , , pk1),…, (Δn, hn, rn, sn, pkn)] trong đó Δi là một số khối sao cho Δi≤Δj đối với i≤j và các phần tử còn lại là các thành phần của chữ ký được tìm thấy trong một giao dịch của khối Δi. Sau đó, chúng tôi xử lý các mục này theo thứ tự như sau. Chúng tôi thêm mỗi chữ ký si = k − 1 ( + ) cho khóa công khai pki trong khối Δi vào cơ sở dữ liệu, cho phép chúng tôi nhanh chóng xác định các giá trị r trùng lặp cũng như chữ ký của chúng. Mỗi giá trị r trùng lặp được xác định sau đó được thêm vào đồ thị G cùng với pki khóa công khai đã sử dụng. Tuy nhiên, trước khi thêm 2 nút này vào đồ thị, chúng tôi thực hiện một vài kiểm tra. Đầu tiên, chúng tôi kiểm tra xem chúng tôi có bị rò rỉ cả ki và trượt tuyết hay không, trong trường hợp đó chúng tôi hoàn toàn có thể bỏ qua cả hai, vì thêm chúng sẽ không dẫn đến rò rỉ mới. Thứ hai, chúng tôi kiểm tra xem G đã chứa cạnh {, } chưa, trong trường hợp đó chúng tôi có thể rò rỉ cả ki và trượt. Thứ ba, chúng tôi kiểm tra xem chúng tôi có bị rò rỉ ki hoặc ki hay không, trong trường hợp đó, chúng tôi có thể rò rỉ đồ trượt tuyết hoặc ki, tương ứng. Trong hai trường hợp cuối cùng, chúng ta cũng có thể rò rỉ các bí mật tương ứng với tất cả các nút có thể truy cập được từ cả ri và pki như đã thảo luận trước đây. Chỉ khi không có điều kiện nào trong ba điều kiện này áp dụng, chúng tôi thêm cạnh {, } vào G. Sau khi xử lý tất cả các chữ ký của một khối, chúng tôi tìm kiếm các chu trình trong G để xác định các hệ phương trình tuyến tính có thể giải được nhằm làm rò rỉ bí mật như đã nêu trước đó . Bất cứ khi nào chúng tôi tìm thấy một rò rỉ mới, chúng tôi đảm bảo rằng chúng tôi xóa các chữ ký tương ứng khỏi cơ sở dữ liệu và chúng tôi xóa các nút tương ứng và các cạnh của chúng khỏi G, vì nếu không, chúng tôi sẽ xem xét lại các giá trị và chu kỳ r tương tự.
Hình 3.3 Số Bitcoin có thể đánh cắp và số lượng địa chỉ Bitcoin dễ bị tấn công do ECDSA không được sử dụng lại theo thời gian.
Bằng cách sử dụng phương pháp này, chúng tôi đã tìm cách rò rỉ 892 trong số 1.550 nút có thể có (Mở hình ảnh trong cửa sổ mới) và 2,537 trong số 4.433 khóa bí mật được sử dụng cùng với các nút này (Mở hình ảnh trong cửa sổ mới). Tổng cộng, điều này cho phép chúng ta kiểm soát lý thuyết đối với số dư của 5.074 địa chỉ, tức là hai địa chỉ trên mỗi khóa. Trong toàn bộ hoạt động này, chúng tôi đã xác định được 23 chu kỳ trong đồ thị và chu kỳ dài nhất bao gồm 12 nút, đại diện cho một hệ thống gồm 12 phương trình tuyến tính và 12 ẩn số (6 phím số + 6 khóa bí mật). Hình dạng cuối cùng của G không chứa bất kỳ chu kỳ nào nữa, có nghĩa là chúng ta đã tiết lộ số bí mật tối đa.
Chúng tôi coi một địa chỉ tại một khối nhất định dễ bị tấn công nếu chúng tôi đã làm rò rỉ khóa của địa chỉ và nếu nó giữ số dư tại khối đó. Có một số mức tăng đột biến đáng chú ý đối với cả số lượng Bitcoin có thể đánh cắp cũng như số lượng địa chỉ dễ bị tấn công. Mức tăng đột biến đáng kể đầu tiên xảy ra khoảng giữa khối 221.000 và khối 227.000, trong đó số dư có thể đánh cắp cao nhất là 533,82 BTC. Thật thú vị, chỉ có một địa chỉ dễ bị tấn công trong thời gian tăng đột biến này. Mức tăng đột biến tiếp theo xảy ra khoảng giữa khối 296.000 và khối 298.000 với số dư có thể đánh cắp cao nhất là 20 BTC, có thể đánh cắp được trong khoảng thời gian 3 khối từ khối 297283 cho đến khối 297285. Từ khối 297,261 đến khối
297.304 có 90 địa chỉ dễ bị tấn công, cũng là số lượng địa chỉ dễ bị tấn công tối đa. Đợt tăng đột biến tiếp theo ngắn hơn một chút và xảy ra ở khoảng khối 333.300 và kéo dài khoảng cho đến khối 333.600. Trong khoảng thời gian này, kẻ tấn công có thể đã đánh cắp tới 266,73 BTC tại khối 333.387 và có 290 địa chỉ dễ bị tấn công ở khối 333.393. Tiếp theo là hai đợt tăng đột biến kéo dài tương tự giữa các khối 365,000 và 366,000 và các khối 374,000 và 375,000. Trong trường hợp trước, 11,21 BTC có thể bị đánh cắp và có 131 địa chỉ dễ bị tấn công vào một số thời điểm, và trong trường hợp thứ hai, 15,41 BTC có thể bị đánh cắp và có 769 địa chỉ dễ bị đánh cắp từ khối 374,386 đến 374,386. Đây cũng là số lượng lớn nhất các địa chỉ dễ bị tấn công tại một thời điểm trong toàn bộ khoảng thời gian. Cuối cùng, trong khi số lượng địa chỉ dễ bị tấn công đột ngột tăng lên 289 tại khối 475,963, chỉ có 0,0064 BTC có thể ăn cắp ở mức cao nhất. Ở trạng thái hiện tại của bản sao blockchain của chúng tôi, có 5 địa chỉ dễ bị tấn công đang giữ số dư tích lũy là 4002 satoshi, tức là 0,00004002 BTC, không có khả năng bị đánh cắp với phí giao dịch hiện tại.
Hình 3.4 Số Bitcoin mà kẻ tấn công có thể đã đánh cắp dựa trên ngưỡng số dư.
Để đánh giá mức độ mà kẻ tấn công có thể đã đánh cắp theo thời gian, chúng tôi xem xét hai tình huống. Đầu tiên, chúng tôi giả sử một kẻ tấn công đánh cắp số dư cao nhất của mỗi địa chỉ theo thời gian. Tức là, chúng tôi lấy tổng số dư cao nhất của mỗi địa chỉ, cho tổng cộng 1021,58 BTC. Ở đây, chúng tôi mặc nhiên cho rằng chủ sở hữu nhận thấy gian lận và do đó chúng tôi bỏ qua tất cả các khoản tiền trong tương lai. Tuy nhiên, mô hình tấn công này đòi hỏi kẻ tấn công phải biết trước số dư đỉnh, điều này không thực tế. Do đó, chúng tôi xem xét một kịch bản tấn công thứ hai thực tế hơn, trong đó kẻ tấn công xác định ngưỡng cân bằng ϵ. Trong cài đặt này, kẻ tấn công chỉ đánh cắp số dư nếu nó bằng hoặc lớn hơn ϵ và chúng tôi giả định một lần nữa rằng chúng tôi chỉ có thể lấy cắp một lần từ một địa chỉ. Hình 3 vẽ sơ đồ số Bitcoin mà kẻ tấn công có thể đã đánh cắp trong trường hợp này tùy thuộc vào ϵ. Chúng tôi để ϵ nằm trong khoảng từ 0 đến 1 BTC với số gia tăng 0,001. Ngưỡng số dư tối ưu theo hàm được vẽ là ϵ = 0,125, mà kẻ tấn công có thể đã sử dụng để đánh cắp 412,80 BTC. Lưu ý rằng mặc dù chỉ một địa chỉ đã có số dư 533,82 BTC tại một số thời điểm, điều đó không có nghĩa là kẻ tấn công trong cài đặt này có thể đánh cắp hoàn toàn. Điều này là do chúng tôi giả định rằng chúng tôi chỉ có thể lấy cắp một lần từ một địa chỉ khi số dư của địa chỉ đó vượt qua ngưỡng số dư ϵ, sau đó chúng tôi giả định một cách thận trọng rằng chủ sở hữu của địa chỉ nhận thức được vấn đề. Mặc dù điều này có nghĩa là việc chọn một ϵ lớn chẳng hạn như ϵ = 500 BTC sẽ mang lại lợi nhuận lớn hơn cho kẻ tấn công, chúng tôi tin rằng đó không phải là một lựa chọn tối ưu. Với giá trị hiện tại của Bitcoin, chúng tôi tin rằng việc một cá nhân giữ số dư lớn như vậy là không thực tế. Ngoài ra, nếu chúng ta giả định rằng có nhiều kẻ tấn công cạnh tranh, thì chúng ta cũng phải cân nhắc điều này khi chọn ϵ. Do đó, chúng tôi để ϵ nằm trong
khoảng từ 0 đến 1 BTC vì chúng tôi tin rằng đây là sự thỏa hiệp tốt giữa những gì hiện tại là thực tế và những gì là tối ưu trên lý thuyết. Sau khi tối ưu nói trên, số lượng BTC bắt đầu giảm mạnh và đối với ϵ = 1, có 359,04 Bitcoin có thể ăn cắp, tức là hình ảnh Mở trong cửa sổ mới ít hơn trong trường hợp tối ưu. Tương tự như phân tích OSINT trước đây của chúng tôi trong Sect. 3.2, chúng tôi cũng bỏ qua phí giao dịch ở đây do tác động không đáng kể của chúng. Ngoài ra, chúng tôi cũng không xem xét việc chặn các giao dịch trong trường hợp này, vì kẻ tấn công giám sát các giao dịch có thể tạo ra các giao dịch ăn cắp càng sớm càng tốt.
3.6 Xác định các cuộc tấn công trong quá khứ
Do hiện tượng ECDSA không được sử dụng lại là một vấn đề đã biết, chúng tôi hiện đang cố gắng đánh giá xem liệu nó có từng bị những kẻ tấn công sử dụng trong quá khứ để đánh cắp Bitcoin hay không. Để thực hiện điều này, chúng tôi đã cố gắng xác định từng điểm trong số 7 mức tăng đột biến trong Hình 2 vào đúng thời điểm số lượng Bitcoin có thể ăn cắp đột ngột giảm xuống. Sau đó, chúng tôi cố gắng tìm các giao dịch, được tạo trong thời gian đó và đầu ra của nó tham chiếu đến đầu vào của nhiều địa chỉ dễ bị tấn công. Trong trường hợp lần tăng đột biến đầu tiên, thật khó để tranh cãi liệu nó có bị kẻ tấn công sử dụng hay không vì chỉ có 1 địa chỉ dễ bị tấn công trong khoảng thời gian này. Tuy nhiên, chúng tôi đã xác định được một số trường hợp số dư của địa chỉ đột ngột giảm hơn 99,99%, mà người ta có thể tranh luận là sự cố Bitcoin đã bị đánh cắp. Trong lần tăng đột biến thứ hai, thứ ba, thứ sáu và thứ bảy, chúng tôi đã tìm thấy các trường hợp số lượng Bitcoin có thể ăn cắp giảm đột ngột và chúng tôi xác định trong mọi trường hợp, một giao dịch duy nhất tham chiếu đến tất cả các địa chỉ dễ bị tấn công, điều này khiến chúng tôi tin rằng Bitcoin đã bị đánh cắp. Tuy nhiên, trong trường hợp tăng đột biến cuối cùng, chỉ có 0,00064 BTC bị đánh cắp.
Hình 3.5 So sánh mức tăng đột biến trong đó Bitcoin có thể đã bị đánh cắp do sụt giảm đột ngột số Bitcoin có thể ăn cắp (trái) và trường hợp chúng tôi thấy mức giảm nhẹ cho thấy rằng không có đồng xu nào có thể bị đánh cắp (phải).
Về mức tăng đột biến thứ tư và thứ năm, chúng tôi không quan sát thấy sự sụt giảm đáng ngờ tương tự về số lượng Bitcoin, mà chỉ liên quan đến số lượng địa chỉ dễ bị tấn công. Để thấy sự khác biệt, hãy xem xét Hình 4, hiển thị và so sánh hình ảnh phóng to của mức tăng đột biến thứ hai và thứ năm. Trước đây, chúng ta có thể thấy sự sụt giảm đột ngột về số lượng Bitcoin có thể ăn cắp, tức là trong khi có 7,49 BTC có thể ăn cắp ở khối 297.304, chỉ có 0,2 BTC có thể ăn cắp ở khối 297.305. Chúng tôi đã xác định được một giao dịch duy nhất đã chuyển tất cả số Bitcoin có thể đánh cắp được, cho thấy có hành vi trộm cắp. Thực tế là số lượng các địa chỉ dễ bị tấn công không giảm xuống 0 cùng một lúc có thể được giải thích bởi nhiều lý do khác nhau. Ví dụ, có thể kẻ tấn công không biết các địa chỉ dễ bị tấn công còn lại. Hoặc, có thể là trường hợp kẻ tấn công đã sử dụng ngưỡng số dư và xác định rằng các địa chỉ còn lại không đáng bị đánh cắp dựa trên ngưỡng này, vì như chúng ta có thể thấy, 0,2 BTC được chia sẻ cho 86 địa chỉ dễ bị tấn công. Trong lần tăng đột biến thứ hai trong Hình 4, chúng tôi quan sát thấy sự sụt giảm mượt mà và đơn điệu theo thời gian liên quan đến số lượng Bitcoin có thể ăn cắp và sau đó là sự giảm đột ngột của số lượng địa chỉ dễ bị tấn công đồng thời với sự sụt giảm BTC có thể đánh cắp. Hiện tượng này có thể được giải thích bởi thực tế là tất cả các địa chỉ đều thuộc về cùng một cá nhân và cuối cùng thì tất cả các địa chỉ được gọi là thay đổi đều được làm trống bởi ví. Địa chỉ thay đổi là những địa chỉ được sử dụng để tích lũy các đầu ra giao dịch còn sót lại. Ví dụ: nếu một địa chỉ A muốn gửi 1 BTC đến một địa chỉ B bằng cách sử dụng một đầu ra duy nhất, có giá trị 5 BTC, thì giao dịch kết quả sẽ tạo ra hai đầu ra, một đầu ra có giá trị 1 BTC và có thể được sử dụng theo địa chỉ B và một ví trị giá 4 BTC và có thể được chi tiêu bằng địa chỉ thay đổi thuộc về chủ sở hữu của A. Giao dịch cuối cùng của ví sau đó sẽ sử dụng tất cả kết quả đầu ra tích lũy của các địa chỉ thay đổi, đây có thể là lời giải thích cho sự sụt giảm đột ngột.
To de ECDSA khong duoc su dung lai, co the ap dung mot so dieu kien. Một trong những giải pháp như vậy được đề xuất bởi RFC 6979 [19] is select nonce k một cách xác định dựa trên thông tin m và khóa s k. Khi các đầu vào khác nhau, bản đồ này cung cấp các điểm khác biệt và tăng cường chống lại việc sử dụng lại không liên tục. Tuy nhiên, vì nó giải thích ngược lại với ECDSA sơ đồ, nên điều đó có nghĩa là các đồng nghiệp cũng không phải tuân theo đề xuất này. Đặc biệt, người ta không thể xác định được rằng ký hiệu đã được tạo ra với sự xác định
không chọn lọc như được đề xuất bởi RFC 6979. Một cách khác để giải quyết vấn đề này là kết hợp kiểm tra nonce lặp lại vào Bitcoin giao thức . Ví dụ: kiểm tra trùng lặp r giá trị có thể được đưa vào giao dịch minh họa quy định. Mỗi người ngang hàng xác minh từng giao dịch của một khối, bao gồm các ký tự xác minh và các tỉnh kiểm tra khác nhau. Ở đây, giao thức cũng có thể hỗ trợ kiểm tra các giá trị rcác lặp đi lặp lại, tức là kiểm tra, cho mỗi r giá trị của mỗi ký tự, nếu nó xuất hiện trong khối chuỗi. Suất hiệu suất từ, bộ lọc Bloom có thể giúp mở rộng chương trình này. Càng nhiều đồng nghiệp tuân theo điều này, thì càng có ít khả năng một giao dịch chứa các phần lặp lặp giá trị r sẽ được thêm vào blockchain. Tuy nhiên, công cụ giám sát mempool thay thế vì blockchain vẫn có thể quan sát các giao dịch chứa các lặp lại giá trị r. Do đó, người ta sẽ cần phải điều chỉnh bổ sung các mạng lưới quy tắc cho một quy tắc mới được thêm vào, điều này không khuyến khích việc phân phối các giao dịch chứa các nonces trùng lặp. If a delivery as such to a a giao dịch ngang hàng tuân theo quy tắc mới này, thì rgiá trị bản sao sẽ được phát hiện và giao dịch sẽ không thể chuyển tiếp nữa. Ngoài ra, người gửi hàng ngang giao dịch phải được thông báo bằng một lỗi thông báo về sự cố gắng tạo ra nhận thức. Càng nhiều đồng nghiệp tuân theo quy tắc mới này, thì các giao dịch có thể chứa các lặp lại giá trị được phân phối trong mạng càng ít. Nói chung, chúng tôi tin rằng việc áp dụng tất cả các đề xuất, tức là ECDSA xác định và điều chỉnh các mạng quy tắc cũng như quy trình xác minh giao dịch, là đủ phương tiện để loại bỏ