Từ cuối tháng 12 năm 2024 đến cuối tháng 1 năm 2025, SSP đã trải qua ba cuộc kiểm toán an ninh độc lập với Halborn, công ty đứng sau các cuộc đánh giá an ninh cho các dự án trên toàn ngăn xếp Web3. Các cuộc đánh giá đã bao quát ba trụ cột của SSP — các ứng dụng wallet và key, các smart contract phía sau multisig ERC-4337, và SDK mà các nhà phát triển khác có thể tích hợp với. Cả ba báo cáo đều công khai.
Bài viết này là một bản tóm tắt ngắn: phạm vi gồm những gì, mỗi cuộc kiểm toán diễn ra trong những ngày nào, Halborn đã tìm thấy gì, và bạn có thể tự đọc các báo cáo ở đâu.
Tóm tắt
- Ba cuộc kiểm toán trong một cửa sổ thời gian (23 tháng 12 năm 2024 – 22 tháng 1 năm 2025).
- Phạm vi: tiện ích trình duyệt SSP Wallet và ứng dụng di động SSP Key, máy chủ relay mà chúng giao tiếp qua, các smart contract ERC-4337 + Schnorr trên Ethereum, và SDK công khai.
- Phát hiện: không có vấn đề nghiêm trọng hay cao. Một số ít phát hiện mức độ thấp và mang tính thông tin — phần lớn nằm ở các đường dẫn mã không sử dụng hoặc đã chết — tất cả đều đã được xử lý.
- Các báo cáo công khai trên trang Halborn và được phản ánh trong các kho mã nguồn SSP.
Ba cuộc kiểm toán, một cửa sổ
Các cuộc kiểm toán được chạy song song thay vì lần lượt, điều này hơi bất thường với một dự án có quy mô như SSP. Lý do mang tính cấu trúc: ba thành phần mà Halborn xem xét nói chuyện với nhau liên tục, và threat model của mỗi thành phần giả định những đảm bảo cụ thể từ hai thành phần kia. Kiểm toán chúng trong cùng một cửa sổ đã cho Halborn một góc nhìn đầy đủ về cách một giao dịch SSP thực sự chảy từ trình duyệt, qua relay, vào smart contract và quay lại — thay vì một lát cắt mỗi lần.
1. SSP Wallet, SSP Key và SSP Relay
Ngày: 30 tháng 12 năm 2024 – 22 tháng 1 năm 2025 Báo cáo công khai: halborn.com — SSP Wallet, Relay & Key
Đây là cuộc khảo sát rộng nhất. Halborn đã xem xét:
- Ứng dụng client tiện ích trình duyệt (sinh khóa, mã hóa khi lưu, các luồng ký).
- Ứng dụng đồng hành di động (Android và iOS) giữ chìa khóa thứ hai trong thiết lập multisig 2/2 của SSP.
- Máy chủ relay làm trung gian thông điệp giữa hai bên — bao gồm hình dạng giao thức và cách nó chịu được lưu lượng độc hại hoặc dị dạng.
- Các nguyên thủy mã hóa được dùng end-to-end: cách seed được sinh ra, cách AES-GCM được áp dụng, cách chữ ký được tạo và xác minh.
- Các cơ chế 2FA được xếp lớp bên trên.
Nếu bạn đã dùng SSP, gần như mọi thứ bạn chạm trực tiếp đều nằm trong phạm vi của cuộc kiểm toán này.
2. Smart contract: ERC-4337 + Schnorr
Ngày: 23 tháng 12 năm 2024 – 3 tháng 1 năm 2025 Báo cáo công khai: halborn.com — Account Abstraction Schnorr MultiSig
Phía on-chain của SSP — phần triển khai account abstraction trên Ethereum và các chuỗi tương thích EVM — là một codebase riêng với threat model khác. Lỗi smart contract không khoan nhượng: một khi hợp đồng đã được triển khai và đang giữ giá trị, bạn không thể vá nó âm thầm.
Phạm vi của Halborn ở đây:
- Việc tích hợp với ERC-4337 EntryPoint và các account contract đặc thù của SSP.
- Tổng hợp chữ ký Schnorr và xác minh on-chain.
- Kiểm soát truy cập, ownership và quy trình upgrade.
- Các pattern tối ưu gas (bao gồm việc liệu có tối ưu nào mở ra footgun hay không).
- Mỗi lệnh gọi bên ngoài mà các hợp đồng thực hiện.
3. SDK
Ngày: 2 tháng 1 – 14 tháng 1 năm 2025 Báo cáo công khai: halborn.com — Schnorr Signatures SDK
Bên thứ ba không chỉ tiêu thụ SSP qua giao diện wallet — họ cũng có thể tích hợp các nguyên thủy account abstraction nền tảng trực tiếp qua SDK. Điều đó khiến SDK trở thành một bề mặt riêng cần được làm cứng: bất cứ default cẩu thả nào nó ship đều trở thành vấn đề-của-mọi-người-import-nó.
Halborn đã xem xét tính tiện dụng của API dưới góc độ an ninh, kiểm tra đầu vào, các thực hành logging an toàn và liệu tài liệu SDK có hướng các integrator tới các pattern sử dụng an toàn thay vì các bẫy thường gặp hay không.
Halborn đã tìm thấy gì
Trên cả ba cuộc kiểm toán cộng lại, con số tiêu đề là không có phát hiện nghiêm trọng và không có phát hiện mức độ cao nào. Các báo cáo có chứa một tập hợp nhỏ các mục mức độ thấp và mang tính thông tin — phần lớn nằm ở các nhánh không dùng đến hoặc đường dẫn mã chết vốn đã được lên kế hoạch loại bỏ. Mọi mục được nêu đều được xử lý trước khi báo cáo được công bố.
Mệnh đề cuối đó quan trọng. "Đã được kiểm toán" tự thân nó là một tuyên bố yếu nếu các phát hiện vẫn nằm đó chưa sửa. Phiên bản SSP mà bạn có thể cài đặt hôm nay là phiên bản đã bao gồm các bản vá hậu kiểm toán.
Điều này có ý nghĩa gì với bạn
Một cuộc kiểm toán sạch là một bức ảnh chụp nhanh, không phải một lời hứa vĩnh cửu. Mã mới đáp xuống, các dependency thay đổi, và threat model tiến hóa. Nhưng các đợt đánh giá năm 2025 cho bạn ba thứ trước đây bạn không có:
- Xác nhận độc lập về mặt mã hóa. Tuyên bố an ninh của SSP nằm ở multisig 2/2 thực sự với mỗi chìa khóa trên một thiết bị riêng. Halborn đã xem cách các chìa khóa được sinh ra, cách chúng được lưu trữ, và cách chúng được kết hợp thành chữ ký. Giao thức khớp với tuyên bố.
- Một threat model công khai. Các báo cáo mô tả những gì đã được kiểm tra, không chỉ những gì đã được tìm thấy. Nếu bạn đang đánh giá SSP cho self-custody, bạn có thể đọc cùng các tài liệu phạm vi mà Halborn đã làm việc dựa trên đó.
- Một mốc bảo trì. Các phiên bản SSP trong tương lai sẽ được đo so với baseline hậu kiểm toán. Nếu có gì đó bị regress, diff sẽ hiển thị.
Cách bạn tự xác minh
Bạn không cần phải tin lời bài viết này về bất kỳ điều gì. Các PDF đầy đủ được liên kết ở trên trên trang Halborn, và đội SSP phản ánh chúng trong kho mã tài liệu của dự án — bao gồm chỉ mục tóm tắt kiểm toán trong ssp-docs. Mỗi PDF bao gồm phương pháp luận, danh sách phát hiện đầy đủ, các xếp hạng mức độ và trạng thái remediation. Chúng được viết cho người đọc là kỹ sư bảo mật nhưng vẫn dễ tiếp cận.
Nếu bạn muốn bắt đầu với chính giao thức trước khi xem cuộc kiểm toán, bài giới thiệu về multisig 2/2 là điểm vào đúng đắn.