Kiến trúc bảo mật của Remio, nói thẳng.

§01 · Tóm tắt tổng quan

Remio là một ứng dụng remote desktop dựng trên kiến trúc zero-knowledge, ngang hàng (peer-to-peer). Nội dung màn hình, dữ liệu nhập và luồng âm thanh được mã hoá đầu-cuối giữa các thiết bị bằng DTLS-SRTP chuẩn ngành với AES-256. Khác với các giải pháp tập trung, server signaling của Remio chỉ hỗ trợ thiết lập kết nối ban đầu — nó không bao giờ nhìn thấy, xử lý hay lưu trữ dữ liệu phiên.

Không cần tài khoản, không có mật khẩu nào để bị xâm phạm, không có cơ sở dữ liệu thông tin đăng nhập tập trung. Ghép cặp thiết bị dùng PIN được xác minh bằng khoảng cách gần, và mọi khoá đều phù du (ephemeral) với Perfect Forward Secrecy: kể cả khi một khoá bị lộ, các phiên trước và sau vẫn an toàn về mặt mật mã. Kiến trúc này loại bỏ trọn những nhóm tấn công từng gây khốn đốn cho đối thủ — vì đơn giản là chẳng có gì để đánh cắp.

§02 · Mô hình mối đe doạ

Kiến trúc bảo mật của Remio được thiết kế để chống lại một tập hợp các kịch bản đe doạ liên quan tới việc dùng remote desktop trong cả bối cảnh doanh nghiệp lẫn cá nhân. Chúng tôi nói rõ mình bảo vệ chống lại điều gì và ranh giới tin cậy nằm ở đâu.

Những mối đe doạ chúng tôi bảo vệ chống lại

• Nghe lén. Toàn bộ media (video, audio) và kênh dữ liệu (nhập liệu, bàn phím, con trỏ) được mã hoá lần lượt bằng SRTP và DTLS. Người quan sát mạng chỉ thấy các gói đã mã hoá và không thể tái dựng nội dung phiên.
• Tấn công xen giữa (MITM). Bắt tay DTLS kèm xác minh fingerprint chứng chỉ ngăn chặn việc chặn bắt. Kênh signaling dùng TLS 1.3 với Perfect Forward Secrecy.
• Server bị xâm nhập. Kể cả khi server signaling của chúng tôi bị xâm nhập hoàn toàn, kẻ tấn công cũng chỉ tiếp cận được metadata kết nối (địa chỉ IP, dấu thời gian). Nội dung phiên không bao giờ được truyền qua hay lưu trên server của chúng tôi.
• Truy cập trái phép. Ghép cặp bằng PIN đòi hỏi ở gần vật lý hoặc biết mã PIN được hiển thị. Không tồn tại cơ sở dữ liệu thông tin đăng nhập truy cập-từ-xa nào để tấn công.
• Đánh cắp thông tin đăng nhập. Không mật khẩu, không tài khoản, không kho thông tin đăng nhập tập trung. Sự tin cậy thiết bị được thiết lập qua ghép cặp PIN; token phiên (JWT) tồn tại ngắn và gắn với thiết bị.
• Phát lại phiên (replay). Cơ chế chống phát lại có sẵn của SRTP và số thứ tự (sequence number) của DTLS ngăn các gói bị bắt được phát lại.
• Tấn công chuỗi cung ứng. Mọi tệp nhị phân của Remio đều được ký mã (code-sign). Bản dựng macOS được Apple notarize. Bản dựng iOS chỉ được phân phối duy nhất qua App Store.

Ranh giới tin cậy

Mô hình mối đe doạ của chúng tôi định nghĩa rõ ba ranh giới tin cậy:

1. Ranh giới thiết bị. Mỗi thiết bị chỉ được tin cậy sau khi xác minh PIN. Các lớp bảo vệ cấp hệ điều hành (sandboxing, Keychain, Secure Enclave) bảo vệ dữ liệu trên thiết bị.
2. Ranh giới mạng. Mọi dữ liệu khi truyền đều được mã hoá. Chúng tôi giả định mạng là thù địch.
3. Ranh giới server. Chính server của chúng tôi được coi là relay không đáng tin. Chúng hỗ trợ kết nối nhưng không thể xem nội dung.

§03 · Tổng quan kiến trúc

Remio tách tầng signaling (thiết lập kết nối) khỏi tầng dữ liệu (streaming). Sự tách biệt này là nền tảng cho thiết kế zero-knowledge của chúng tôi — server giúp bạn kết nối không bao giờ chạm tới dữ liệu bạn trao đổi.

Tầng signaling và tầng dữ liệu

Trách nhiệm duy nhất của server signaling là chuyển tiếp SDP offer/answer và ICE candidate giữa các thiết bị trong lúc thiết lập kết nối. Một khi kết nối P2P đã thiết lập, server signaling không còn tham gia nữa.

// Signaling message types (FlatBuffers schema) — signaling.fbs
table SignalingMessage {
    type: MessageType;     // SDP_OFFER, SDP_ANSWER, ICE_CANDIDATE
    payload: [ubyte];      // Opaque to server — encrypted content
    device_id: string;     // Source device identifier
    room_id: string;       // Session room
    timestamp: uint64;     // Unix timestamp
}

Server không thể phân tích nội dung payload — đó là một khối nhị phân (binary blob) mà chỉ thiết bị đích mới diễn giải được. Giao thức nhị phân FlatBuffers bổ sung một lớp cấu trúc khiến các tấn công tiêm (injection) khó hơn so với signaling dựa trên JSON.

§04 · Các lớp mã hoá

Remio áp dụng chiến lược mã hoá nhiều lớp, trong đó mỗi kênh truyền thông dùng giao thức mật mã phù hợp nhất với yêu cầu của nó.

Perfect forward secrecy

Mỗi phiên Remio sinh ra một bộ khoá mã hoá phù du (ephemeral) độc nhất thông qua trao đổi khoá ECDHE.

• Làm lộ khoá phiên hiện tại không làm lộ các phiên trước.
• Làm lộ khoá phiên hiện tại không làm lộ các phiên sau.
• Mỗi cặp khoá chỉ tồn tại trong suốt một phiên duy nhất.
• Khoá không bao giờ được lưu xuống đĩa — chúng chỉ tồn tại trong bộ nhớ.

Bộ mã (cipher suite)

# Supported TLS 1.3 cipher suites (in order of preference)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# DTLS cipher suites
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Xoay vòng khoá

Khoá được tự động xoay vòng tại các mốc sau:

• Bắt đầu phiên. Mỗi kết nối, một lần bắt tay DTLS mới sinh ra khoá mới tinh.
• Suy dẫn khoá SRTP. Khoá media được suy dẫn từ bắt tay DTLS và độc nhất cho từng media track.
• Kết nối lại. Nếu một phiên bị gián đoạn và kết nối lại, một cuộc trao đổi khoá hoàn toàn mới sẽ diễn ra.

§05 · Xác thực và ghép cặp

Remio cố ý tránh xác thực tên-người-dùng/mật-khẩu truyền thống. Thay vào đó, chúng tôi dùng mô hình ghép cặp thiết bị bằng PIN loại bỏ những vector tấn công phổ biến nhất trong phần mềm remote desktop.

Ghép cặp bằng PIN

Khi một client muốn kết nối tới host lần đầu, quy trình diễn ra như sau:

1. Host hiển thị một mã PIN số ngắn trên màn hình (hoặc dưới dạng mã QR).
2. Client nhập PIN, mã này được gửi tới host qua kênh signaling.
3. Host xác thực PIN rồi xác nhận hoặc từ chối việc ghép cặp.
4. Nếu thành công, một quan hệ tin cậy thiết bị được thiết lập.
5. Các kết nối sau từ cùng thiết bị không cần ghép cặp lại.

// Pairing protocol (FlatBuffers) — pairing.fbs
table PairValidateMessage {
    pin: string;             // PIN entered by client
    client_info: ClientInfo; // Device name, platform, version
}

table PairConfirmMessage {
    confirmed: bool;         // Host's decision
    device_id: string;       // Assigned device identifier
    token: string;           // JWT for future sessions
}

Mô hình tin cậy thiết bị

Một khi đã ghép cặp, mỗi thiết bị được nhận dạng bằng một device ID độc nhất. Host duy trì một danh sách cục bộ các thiết bị tin cậy. Quan hệ tin cậy này:

• Lưu cục bộ chỉ trên thiết bị host, trong Keychain của hệ điều hành.
• Không bao giờ được truyền đi — server không hề biết thiết bị nào được tin cậy.
• Có thể thu hồi — host có thể gỡ một thiết bị tin cậy bất cứ lúc nào.

Token phiên (JWT)

Sau khi ghép cặp, các token JWT tồn tại ngắn được dùng để xác thực với server signaling:

// JWT token structure — session_token.json
{
    "iss": "remio-signaling",
    "sub": "device_abc123",
    "exp": 1738886400,        // 24h expiry (configurable)
    "iat": 1738800000,
    "alg": "HS256"            // HMAC-SHA256
}

Các token này xác thực một thiết bị với server signaling để tạo room và chuyển tiếp tin nhắn. Chúng không cấp quyền truy cập nội dung phiên — thứ được bảo vệ bằng một lần bắt tay DTLS riêng.

§06 · Thiết kế zero-knowledge

Zero-knowledge không phải một thuật ngữ tiếp thị ở Remio — nó là một ràng buộc kiến trúc. Hệ thống của chúng tôi được thiết kế để nội dung phiên về mặt cấu trúc là không thể truy cập với Remio, nhân viên của Remio, hay bất kỳ bên thứ ba nào.

Server của chúng tôi có thể thấy gì

• Địa chỉ IP của các thiết bị đang kết nối (cần cho việc kết nối mạng).
• Dấu thời gian kết nối.
• Device ID (định danh mờ đục, không gắn với thông tin cá nhân).
• Metadata signaling: trao đổi SDP offer/answer, ICE candidate.

Server của chúng tôi không thể thấy gì

• Nội dung màn hình — khung hình video được mã hoá SRTP đầu-cuối.
• Âm thanh — cùng lớp mã hoá SRTP như video.
• Sự kiện nhập liệu — chuột, bàn phím, cảm ứng được mã hoá DTLS.
• Vị trí con trỏ — truyền qua kênh dữ liệu đã mã hoá.
• Nội dung tệp — mọi truyền tệp diễn ra qua kênh đã mã hoá.
• Dữ liệu clipboard — kênh dữ liệu đã mã hoá.
• Trạng thái ứng dụng — bạn đang chạy app nào, đang làm gì.

Chính sách lưu giữ dữ liệu

Nhờ kiến trúc P2P, trên thực tế chẳng có gì để lưu giữ:

• Nội dung phiên. Không bao giờ lưu. Chỉ stream thời gian thực.
• Log signaling. Metadata kết nối được giữ tối đa 30 ngày để gỡ lỗi, rồi xoá. Không chứa nội dung phiên.
• Tài khoản người dùng. Không cần tài khoản. Dữ liệu Firebase Auth tuỳ chọn do hạ tầng của Google quản lý và người dùng có thể xoá.
• Thông tin thiết bị. Lưu cục bộ trên từng thiết bị. Không bao giờ tải lên server của chúng tôi.

Luồng dữ liệu ưu tiên P2P

Trong đa số kết nối (khi NAT traversal thành công), dữ liệu chảy trực tiếp giữa các thiết bị mà không chạm tới bất kỳ server nào:

# Best case: direct P2P
Client <—— DTLS-SRTP (encrypted) ——> Host
              ↑ No server involvement

# Fallback: TURN relay
Client <— DTLS-SRTP —> TURN server <— DTLS-SRTP —> Host
                            ↑ Still E2E encrypted
                            ↑ Server sees only encrypted blobs

Ngay cả trong kịch bản dự phòng TURN relay, server relay cũng chỉ xử lý các gói đã mã hoá. Nó hoạt động như một đường ống câm — không thể giải mã, xem hay sửa đổi dữ liệu.

§07 · Bảo mật mạng

Thiết lập kết nối P2P

Remio dùng giao thức ICE (Interactive Connectivity Establishment) để tìm đường kết nối tốt nhất có thể giữa các thiết bị:

1. Host candidate — kết nối LAN trực tiếp trên cùng mạng.
2. Server-reflexive candidate (STUN) — NAT traversal qua server STUN để tìm ra IP công khai.
3. Relay candidate (TURN) — relay đã mã hoá khi không thể thiết lập kết nối trực tiếp.

ICE agent thử đồng thời mọi cặp candidate và chọn đường có độ trễ thấp nhất, đáng tin cậy nhất. P2P trực tiếp luôn được ưu tiên.

Chính sách truyền tải có thể cấu hình

// ICE transport policy options — ice_policy.swift
All       // Default — prefer P2P, fall back to relay
Relay     // Force TURN relay (for strict network policies)
NoHost    // Skip host candidates (no LAN)
None      // Disable ICE (testing only)

Giới hạn tần suất (rate limiting)

Server signaling áp dụng giới hạn tần suất mạnh tay để ngăn lạm dụng:

Các bộ giới hạn tần suất hết hạn được tự động dọn dẹp mỗi 5 phút với TTL 10 phút, ngăn cạn kiệt bộ nhớ do các tấn công phân tán.

Bảo vệ chống DDoS

Hạ tầng signaling của chúng tôi được Cloudflare bảo vệ, cung cấp:

• Anycast DNS với mạng edge toàn cầu.
• Giảm thiểu DDoS ở Layer 3, 4 và 7.
• Web Application Firewall (WAF).
• Giới hạn tần suất tại edge trước khi lưu lượng chạm tới origin.
• Phát hiện bot và trang thử thách (challenge).

§08 · Bảo mật client

Remio tận dụng toàn bộ tầng bảo mật của từng hệ điều hành để bảo vệ dữ liệu cục bộ và đảm bảo tính toàn vẹn của ứng dụng.

macOS

• Tích hợp Keychain. Mọi dữ liệu nhạy cảm (token tin cậy thiết bị, JWT) được lưu trong macOS Keychain, bảo vệ bằng thông tin đăng nhập của người dùng và mã hoá phần cứng.
• App Sandbox. Remio chạy trong môi trường sandbox với quyền tối thiểu. Chụp màn hình và accessibility đòi hỏi người dùng chấp thuận rõ ràng.
• Ký mã (code signing). Mọi bản dựng đều được ký bằng chứng chỉ Apple Developer.
• Notarization. Bản dựng macOS được Apple notarize, xác nhận không chứa mã độc đã biết.
• Hardened runtime. Ngăn tiêm mã, chiếm quyền thư viện (library hijacking) và gỡ lỗi trên bản dựng production.

iOS

• App Transport Security (ATS). Mọi kết nối mạng phải dùng HTTPS/TLS. Không cấu hình ngoại lệ nào.
• Secure Enclave. Ở nơi khả dụng, khoá mật mã được sinh và lưu trong phần cứng Secure Enclave.
• Keychain Services. Thông tin đăng nhập thiết bị được lưu trong iOS Keychain với lớp bảo vệ kSecAttrAccessibleWhenUnlockedThisDeviceOnly.
• Kiểm duyệt App Store. Mọi bản dựng iOS đều vượt qua quy trình kiểm duyệt bảo mật của Apple.
• Không dữ liệu nền. App không thu thập hay truyền dữ liệu khi chạy nền.

Ký mã & xác minh

# Verify Remio macOS binary — verify_signature.sh
$ codesign --verify --deep --strict "Remio Host.app"
# Remio Host.app: valid on disk

$ spctl --assess --verbose "Remio Host.app"
# Remio Host.app: accepted
# source=Notarized Developer ID

§09 · Ứng phó sự cố

Lịch sử bảo mật

Tính đến tháng 2/2026, Remio không có lịch sử vi phạm hay sự cố bảo mật nào. Kiến trúc zero-knowledge của chúng tôi giảm đáng kể bề mặt tấn công — không có cơ sở dữ liệu tập trung về thông tin đăng nhập hay dữ liệu phiên để nhắm tới.

Báo cáo lỗ hổng

Chúng tôi khuyến khích công bố có trách nhiệm từ các nhà nghiên cứu bảo mật. Nếu bạn phát hiện một lỗ hổng tiềm ẩn:

1. Gửi email tới security@remio.net kèm mô tả chi tiết.
2. Kèm các bước tái hiện, nếu có.
3. Chúng tôi xác nhận đã nhận trong vòng 48 giờ.
4. Chúng tôi đặt mục tiêu khắc phục các lỗ hổng đã xác nhận trong vòng 30 ngày.
5. Người báo cáo được ghi nhận trong changelog bảo mật của chúng tôi, trừ khi họ muốn ẩn danh.

Chính sách công bố có trách nhiệm

• Chúng tôi đề nghị một cửa sổ 90 ngày trước khi công bố công khai.
• Chúng tôi không theo đuổi hành động pháp lý với các nhà nghiên cứu hành động thiện chí.
• Chúng tôi ưu tiên vá lỗi theo mức độ nghiêm trọng: nghiêm trọng, cao, trung bình, thấp.
• Một chương trình bug bounty chính thức nằm trong roadmap của chúng tôi.

Quy trình ứng phó sự cố

Trong trường hợp có một vấn đề bảo mật đã xác nhận:

1. Khoanh vùng. Cô lập các hệ thống bị ảnh hưởng trong vòng 1 giờ.
2. Đánh giá. Xác định phạm vi và tác động trong vòng 24 giờ.
3. Truyền thông. Thông báo cho người dùng bị ảnh hưởng trong vòng 72 giờ (tuân thủ GDPR).
4. Khắc phục. Triển khai bản vá qua hạ tầng tự-động-cập-nhật.
5. Hậu kiểm (post-mortem). Công bố một báo cáo minh bạch.

§10 · Tuân thủ

Sẵn sàng cho GDPR

Kiến trúc zero-knowledge của Remio về bản chất thân thiện với GDPR vì chúng tôi giảm thu thập dữ liệu xuống mức tối thiểu tuyệt đối về mặt kỹ thuật:

• Tối thiểu hoá dữ liệu. Chúng tôi chỉ thu thập những gì cần thiết để thiết lập kết nối.
• Quyền được xoá. Vì chúng tôi không lưu nội dung người dùng, chẳng có gì để xoá. Dữ liệu tài khoản tuỳ chọn có thể được xoá theo yêu cầu.
• Khả chuyển dữ liệu. Dữ liệu tin cậy thiết bị được lưu cục bộ và do người dùng kiểm soát.
• Đồng thuận. Ghép cặp PIN là một cơ chế đồng thuận rõ ràng cho từng thiết bị.
• Không truyền dữ liệu nội dung xuyên biên giới. Kết nối P2P giữ dữ liệu giữa các thiết bị; nó không bao giờ đi vào hạ tầng của chúng tôi.

Roadmap SOC 2

Các cột mốc tuân thủ đã lên kế hoạch

• Kiểm toán bảo mật độc lập — kiểm thử xâm nhập chuyên nghiệp và rà soát mã, dự kiến cho 2026.
• SOC 2 Type I — đánh giá kiểm soát tổ chức ban đầu.
• SOC 2 Type II — xác minh tuân thủ liên tục.
• Chương trình bug bounty — phần thưởng công-bố-có-trách-nhiệm chính thức.

Nơi lưu trú dữ liệu

Vì Remio ưu tiên P2P, dữ liệu phiên nằm ở bất cứ nơi nào thiết bị của bạn ở đó. Dữ liệu của bạn không bao giờ rời khỏi kết nối trực tiếp giữa các thiết bị của bạn. Server signaling (đặt tại Cloudflare và DigitalOcean) chỉ xử lý metadata kết nối — và metadata này không gắn với bất kỳ thông tin cá nhân nào.

§11 · So sánh với các lựa chọn khác

Ngành remote desktop từng khốn đốn vì những vụ vi phạm bảo mật đình đám. Đây là cách kiến trúc của Remio khác biệt căn bản so với các lựa chọn tập trung.

Vì sao kiến trúc tập trung thất bại

Vấn đề căn bản của các dịch vụ remote desktop tập trung là một vụ vi phạm duy nhất có thể ảnh hưởng tới toàn bộ người dùng. Khi server production của AnyDesk bị xâm nhập vào tháng 2/2024, kẻ tấn công đã đánh cắp chứng chỉ ký mã, có khả năng cho phép chúng phát tán mã độc nguỵ trang thành phần mềm AnyDesk hợp lệ. Toàn bộ mật khẩu người dùng phải được đặt lại.

Khi APT29 (một nhóm được nhà nước Nga bảo trợ) xâm nhập mạng doanh nghiệp của TeamViewer vào tháng 6/2024, nó đặt ra câu hỏi về tính toàn vẹn của chính sản phẩm — vì một kiến trúc tập trung nghĩa là nhà cung cấp có năng lực kỹ thuật để truy cập các phiên.

Remio loại bỏ hoàn toàn nhóm tấn công này. Một vụ xâm nhập server signaling của chúng tôi chỉ mang lại metadata kết nối. Không có thông tin đăng nhập để đánh cắp, không có phiên để truy cập, không có chứng chỉ nào có thể dùng để ký phần mềm độc hại nhắm vào thiết bị của người dùng chúng tôi.

§12 · Kết luận

Bảo mật của Remio không phải một bộ tính năng gắn thêm vào sản phẩm — nó là hệ quả của những quyết định kiến trúc đưa ra ngay từ ngày đầu. Bằng cách chọn P2P thay vì tập trung, ghép cặp PIN thay vì mật khẩu, zero-knowledge thay vì thu thập dữ liệu, và giao thức mở thay vì hộp đen độc quyền, chúng tôi đã dựng nên một remote desktop nơi bảo mật là trạng thái mặc định, chứ không phải một nâng cấp tuỳ chọn.

Chúng tôi tin rằng quyền riêng tư là không thể tuỳ chọn, và rằng sự tin cậy nên được giành lấy qua sự minh bạch, chứ không phải đòi hỏi qua điều khoản dịch vụ. Sách trắng này là một phần của cam kết đó.

Với các câu hỏi, đánh giá bảo mật doanh nghiệp, hoặc để báo cáo lỗ hổng:

• Câu hỏi bảo mật: security@remio.net
• Bán hàng doanh nghiệp: enterprise@remio.net
• Chung: hello@remio.net