Ghi chú của tác giả: các cuộc tấn công được đề cập trong bài viết này không thể thực hiện được đối với các phiên bản I2P hiện tại.
Là một mạng ngang hàng tự tổ chức, I2P dựa vào các router tham gia mạng để có cách thức chia sẻ thông tin về những gì có trên mạng và cách để tiếp cận chúng. Các router I2P đạt được việc chia sẻ thông tin này bằng cách sử dụng NetDB, một DHT (bảng băm phân tán) dựa trên Kademlia nhưng đã được sửa đổi để hoạt động cho I2P. NetDB cần chia sẻ hai loại mục nhập chính, “RouterInfos” mà các nút ngang hàng sẽ dùng để giao tiếp trực tiếp với các router khác, và “LeaseSets” mà các nút ngang hàng khác sẽ dùng để giao tiếp với các client I2P thông qua các tunnel ẩn danh. Routers thường xuyên trao đổi các mục NetDB với nhau, hoặc bằng cách gửi thông tin tới một router hoặc client, hoặc yêu cầu thông tin từ một router hoặc client. Điều này có nghĩa là các mục có thể đến trực tiếp hoặc gián tiếp, ẩn danh hoặc không ẩn danh, tùy theo nhu cầu của mạng và khả năng của client. Tuy nhiên, là một mạng ẩn danh hóa, điều quan trọng nữa là phải đảm bảo rằng không thể có chuyện thông tin được gửi một cách ẩn danh lại bị yêu cầu truy hồi theo cách không ẩn danh. Cũng cần đảm bảo rằng thông tin được gửi theo cách không ẩn danh thì không thể bị yêu cầu truy hồi một cách ẩn danh. Nếu một trong hai tình huống đó trở nên khả thi, thì có thể thực hiện một tấn công liên kết (linking attack) cho phép kẻ tấn công xác định liệu client và router có đang chia sẻ một cái nhìn chung về NetDB hay không. Nếu có thể xác định một cách đáng tin cậy rằng hai mục tiêu chia sẻ cùng một cái nhìn về NetDB, thì rất có khả năng chúng nằm trên cùng một router, làm suy yếu nghiêm trọng tính ẩn danh của mục tiêu. Bởi vì có rất ít mạng ẩn danh, và I2P là mạng duy nhất mà bảng định tuyến được chia sẻ thông qua hoạt động của một DHT, nên lớp tấn công này gần như là độc nhất với I2P và việc giải quyết nó có ý nghĩa quan trọng đối với thành công của I2P.
Hãy xem xét kịch bản sau: Có một I2P router lưu trữ một I2P client. I2P router công bố một RouterInfo, và I2P client công bố LeaseSet của nó. Vì cả hai đều được công bố trong NetDB, các I2P router khác có thể truy vấn NetDB để tìm ra cách liên lạc với chúng. Đây là điều bình thường và thiết yếu đối với hoạt động của một overlay network (mạng phủ) thuộc kiểu được I2P triển khai. Một kẻ tấn công vận hành một I2P router và truy vấn NetDB để lấy RouterInfo mục tiêu và LeaseSet mục tiêu. Sau đó, nó tạo một LeaseSet mới, duy nhất và thậm chí có thể là giả mạo, và gửi nó qua một tunnel tới LeaseSet của client mà nó đang nhắm mục tiêu tấn công. Client xử lý LeaseSet đã được tạo và thêm nó vào NetDB của chính nó. Kẻ tấn công sau đó yêu cầu trả lại trực tiếp LeaseSet đã tạo, từ router, sử dụng RouterInfo nó lấy được từ NetDB. Nếu LeaseSet đã tạo được nhận lại như một phản hồi, thì kẻ tấn công có thể kết luận rằng client mục tiêu và router mục tiêu đang chia sẻ cùng một cái nhìn chung về NetDB.
Đó là một ví dụ đơn giản về một loại tấn công khử ẩn danh NetDB, dựa vào việc thêm một bản ghi vào NetDB của người khác bằng một danh tính, rồi yêu cầu truy xuất lại bản ghi đó bằng một danh tính khác. Trong trường hợp này, các danh tính được nói tới là danh tính “router” và danh tính “client”. Tuy nhiên, việc liên kết giữa các client, ít gây thiệt hại hơn, cũng có thể xảy ra trong một số thiết kế. Việc thiết kế biện pháp phòng vệ chống lại loại tấn công này đòi hỏi phải cung cấp cho router một cách để xác định liệu có an toàn hay không khi trao đổi một mẩu thông tin với một danh tính tiềm năng.
Vậy chúng ta nên nghĩ về vấn đề này như thế nào? Điều chúng ta đang xử lý ở đây, thực ra, liên quan đến khả năng liên kết giữa các “danh tính” khác nhau trên mạng. Khả năng liên kết này xuất hiện vì tất cả các danh tính đó dùng chung một cấu trúc dữ liệu “ghi nhớ” những ai nó đã giao tiếp với, và những ai đã giao tiếp với nó. Nó cũng “ghi nhớ” cách thức cuộc giao tiếp đó đã diễn ra.
Trong giây lát, hãy tưởng tượng chúng ta là kẻ tấn công. Hãy tưởng tượng bạn đang cố khám phá danh tính của một bậc thầy cải trang. Bạn chắc chắn rằng mình đã từng thấy khuôn mặt thật của hắn, và bạn cũng chắc chắn rằng mình thường xuyên giao tiếp với một trong những lớp cải trang của hắn. Bạn sẽ làm thế nào để xác lập rằng danh tính cải trang và danh tính thật thuộc về cùng một người? Tôi có thể nói với người đang cải trang một bí mật. Nếu người không cải trang phản hồi bằng cách sử dụng thông tin bí mật đó, thì tôi có thể xác định rằng người không cải trang biết bí mật này. Giả định rằng người cải trang không tiết lộ bí mật đó cho ai khác, tôi có thể suy ra rằng người không cải trang và người cải trang thực ra là cùng một người. Dù bậc thầy cải trang có đeo bao nhiêu chiếc mặt nạ đi nữa, hắn cũng chỉ có một tâm trí.
Để bảo vệ hiệu quả danh tính của các ứng dụng khách I2P, I2P cần có khả năng đóng vai một bậc thầy ngụy trang còn giỏi hơn so với “bậc thầy ngụy trang” được mô tả ở trên. Nó cần có khả năng “ghi nhớ” một số thông tin quan trọng về cách nó đã tham gia vào NetDB và phản hồi phù hợp dựa trên các chi tiết đó. Nó phải có khả năng nhớ lại:
- Whether a NetDB Entry was received directly, or received down a client tunnel
- Whether a NetDB Entry was sent by a peer in response to our lookup, or sent unsolicited
- Which NetDB Entry was received down Which client Tunnel
- Multiple versions of the same entry for different client tunnels
Về mặt cấu trúc, cách dễ hiểu và đáng tin cậy nhất để xử lý mẫu này là sử dụng “Sub-DBs.” Sub-DB (cơ sở dữ liệu con) là các NetDB thu nhỏ, giúp NetDB tổ chức các bản ghi mà không bị thất lạc. Mỗi client có một Sub-DB riêng để sử dụng, và bản thân router có một NetDB đầy đủ chức năng. Sử dụng Sub-DB, chúng ta trao cho bậc thầy cải trang của mình một danh bạ các bí mật được sắp xếp theo người đã chia sẻ những bí mật đó với anh ta. Khi một yêu cầu được gửi tới client, nó chỉ tìm các bản ghi đã được gửi tới client, và khi một yêu cầu được gửi tới router, chỉ NetDB ở cấp toàn router được sử dụng. Bằng cách làm như vậy, chúng ta không chỉ giải quyết dạng đơn giản nhất của cuộc tấn công, mà còn làm suy yếu hiệu lực của cả một lớp tấn công.