Trong hầu hết hệ thống, mật mã thường chỉ là lớp phủ:
- bật TLS
- bật mã hoá ổ đĩa
- thêm JWT hoặc token
OBELISK tiếp cận hoàn toàn khác: Cryptography không phải tính năng – nó là cấu trúc chịu lực của toàn bộ hệ thống.
Bài viết này không đi sâu vào thuật toán cụ thể, mà tập trung vào kiến trúc và nguyên tắc mật mã trong OBELISK.
Checklist nhanh: Cryptographic Design của OBELISK có phù hợp với bạn không?
- ✅ Bạn coi mật mã là nền móng, không chỉ là lớp phủ
- ✅ Bạn chấp nhận capability thay vì token danh tính truyền thống
- ✅ Bạn cần giới hạn thiệt hại ngay cả khi key bị lộ
- ✅ Bạn ưu tiên object-level encryption hơn full-disk encryption
- ✅ Bạn muốn stateless verification, không session dài hạn
- ✅ Bạn sẵn sàng ràng buộc chặt crypto với ngữ cảnh hành động
- ❌ Bạn cần token mang đầy đủ thông tin user/group
- ❌ Bạn muốn key “toàn năng” để đơn giản hoá vận hành
- ❌ Bạn chấp nhận token sống lâu “cho tiện”
- ❌ Bạn tin rằng chỉ bật TLS + FDE là đủ
→ Nếu tick ít nhất 4 ô đầu → Đây chính là cách tiếp cận bạn cần. → Nếu tick nhiều ô dưới → OBELISK crypto sẽ gây ma sát không đáng có.
1️⃣ Không tin vào “crypto đúng là đủ”
Một hệ thống có thể dùng:
- AES-256
- TLS 1.3
- Ed25519 / RSA-4096
- Key siêu dài
…và vẫn mất dữ liệu hàng loạt.
Lý do không nằm ở thuật toán, mà ở:
- ❌ Key dùng sai chỗ
- ❌ Scope quá rộng
- ❌ Quyền không bị giới hạn
- ❌ Crypto không gắn với ngữ cảnh
OBELISK coi mật mã là công cụ giới hạn thiệt hại, không phải bùa hộ mệnh.
2️⃣ Nguyên tắc cốt lõi của Cryptographic Design
Thiết kế crypto xoay quanh 6 nguyên tắc bất di bất dịch:
- 🗸 Data-centric, không user-centric
- 🗸 Key không bao giờ toàn năng
- 🗸 Mỗi quyền = một bằng chứng mật mã
- 🗸 Crypto phải ràng buộc ngữ cảnh
- 🗸 Không giữ state dài hạn
- 🗸 Giả định key sẽ bị lộ – và vẫn phải sống sót
3️⃣ Capability là primitive mật mã, không phải token
Trong OBELISK, capability không phải JWT, cũng không phải session token. Capability là:
- ✅ Cấu trúc dữ liệu tự chứa
- ✅ Niêm phong bằng AEAD
- ✅ Ràng buộc chặt với hành động, resource, thời gian, ngữ cảnh
Nó chỉ trả lời một câu hỏi: Hành động X trên tài nguyên Y, trong khoảng thời gian T, có hợp lệ không?
Không trả lời:
- Bạn là ai
- Bạn đăng nhập lúc nào
- Bạn thuộc nhóm nào
4️⃣ AEAD ở mọi ranh giới quan trọng
OBELISK dùng AEAD như nguyên tắc thiết kế, không chỉ là lựa chọn thuật toán. AEAD được áp dụng để:
- ✅ Niêm phong capability
- ✅ Xác thực request header
- ✅ Bảo vệ object data
- ✅ Chống sửa đổi ngữ cảnh
Quan trọng không phải AES-GCM hay XChaCha20, mà là: Không dữ liệu quan trọng nào tồn tại mà thiếu tính toàn vẹn.
5️⃣ Ràng buộc crypto với ngữ cảnh (Context Binding)
Lỗi phổ biến: token hợp lệ ở mọi nơi, key dùng cho nhiều mục đích.
OBELISK không cho phép:
- Capability ràng buộc với server identity, protocol version, action cụ thể
- Object key ràng buộc với object ID, salt riêng, mục đích sử dụng
Một bằng chứng mật mã không thể tái sử dụng ngoài ngữ cảnh nó sinh ra.
6️⃣ Key hierarchy – không có “master key toàn năng”
OBELISK xây dựng key hierarchy rõ ràng:
- Root key → chỉ dùng để dẫn xuất
- Capability sealing key → chỉ niêm phong capability
- Storage master key → chỉ dẫn xuất object key
- Object key → chỉ dùng cho một object
Không có key nào vừa ký request, vừa mã hoá dữ liệu, vừa xác thực user. Mỗi key chỉ có một vai trò duy nhất.
7️⃣ Object-level encryption thay vì “mã hoá cả ổ”
OBELISK không tin vào việc chỉ bật full-disk encryption (FDE).
Lý do:
- ❌ Khi hệ thống chạy, dữ liệu vẫn plaintext trong process
- ❌ Exploit runtime bỏ qua hoàn toàn FDE
Vì vậy:
- ✅ Mỗi object được mã hoá riêng
- ✅ Key dẫn xuất riêng
- ✅ Compromise một object không mở ra object khác
Mục tiêu: Không ai đọc được nhiều hơn mức cho phép.
8️⃣ Stateless verification – crypto thay thế session
OBELISK tránh session và state dài hạn. Thay vào đó:
- ✅ Mỗi request mang theo bằng chứng mật mã
- ✅ Server chỉ verify, không ghi nhớ
Lợi ích:
- Giảm attack surface
- Tránh session hijacking
- Dễ scale
- Khó abuse logic
Crypto thay thế state, không bổ sung thêm state.
9️⃣ Giả định key sẽ bị lộ
Giả định quan trọng: Key có thể bị lộ. Câu hỏi thực sự: Hậu quả tới đâu?
OBELISK đảm bảo:
- Lộ capability → Chỉ ảnh hưởng một hành động, thời gian ngắn
- Lộ object key → Chỉ ảnh hưởng một object
- Lộ process memory → Bị giới hạn bởi jail + MAC
Không có tình huống “lộ một thứ → mất tất cả”.
🔟 Điều OBELISK cố ý không làm trong crypto
OBELISK từ chối:
- ❌ Tự thiết kế thuật toán
- ❌ Dựa vào security by obscurity
- ❌ Dùng một key cho nhiều mục đích
- ❌ Nhét logic business vào chữ ký
- ❌ Kéo dài thời gian sống của token “cho tiện”
Crypto ở đây là kỷ luật, không phải mẹo vặt.
