uOS는 채팅·메일·영상 회의·파일·문서·일정·AI 도구 등을 한곳에 모은 브라우저 기반 업무 공간이다. 제작자는 콘텐츠를 사용자 기기에서 암호화해 서버에 보내므로 서비스 운영자도 내용을 읽을 수 없다고 설명한다. 다만 서비스는 현재 알파 단계이며, 독립 보안 감사는 아직 받지 않았다.
uOS는 계정과 콘텐츠에 양자내성 암호와 기존 암호를 함께 적용한다. 제작자에 따르면 새 키에는 2026년 9월부터 ML-KEM-1024와 ML-DSA-87을 쓰며, 기존 계정도 세 비밀 정보를 사용해 다음 로그인할 때 해당 방식으로 이전한다. 이전 전까지는 일부 계정이 구형 v2 키를 유지한다. 연결은 지원 브라우저에서 하이브리드 TLS 그룹 X25519MLKEM768을 협상하지만, 앱 자체를 브라우저에 전달하는 과정은 TLS에 의존한다.
계정과 암호화 방식
계정은 서버에 저장된 사용자 이름과 비밀번호가 아니라, 기기에서 만든 암호화 키 쌍으로 구성된다. 가입할 때 브라우저는 32바이트 ML-DSA 시드와 64바이트 ML-KEM 시드를 생성한다. 사용자는 최소 12자 비밀 정보와 최소 20자 암호문구, 이메일 형식의 계정 식별자를 정한다. 브라우저는 Argon2id로 키를 만들어 시드 묶음을 암호화하고, 서버에는 암호화된 묶음과 공개 키 등을 저장한다. 서버는 비밀 정보나 평문 식별자를 보관하지 않는다.
KEK = Argon2id(NFKC(S1) ‖ 0 ‖ NFKC(S2) ‖ 0 ‖ NFKC(identifier) ‖ 0, salt₃₂, m = 256 MiB, t = 3, p = 2)
wrapped = XChaCha20-Poly1305(KEK, nonce₂₄, seed bundle, AAD = account id ‖ KDF version ‖ secret epoch)
두 비밀 정보와 식별자는 유니코드 NFKC로 정규화하고 앞뒤 공백을 없앤 뒤 0바이트로 구분한다. 로그인 때 브라우저가 비밀 정보로 묶음을 푼다. 서버는 Argon2id 결과에서 로그인 키도 파생해 검증하지만, 이 방식은 OPAQUE가 아니며 로그인 중 서버가 로그인 키를 본다. 잘못된 비밀 정보와 존재하지 않는 계정에는 같은 거절 응답을 보내고, 계정·주소별 시도 횟수를 제한한다. 데이터베이스 복사본을 가진 공격자는 오프라인 추측을 시도할 수 있으며, 추측마다 256MiB Argon2id 계산이 필요하다. 운영자는 계정을 재설정하거나 복구할 수 없다. 비밀 정보와 복구 자료를 모두 잃으면 계정을 복구할 수 없다.
사용자는 복구 공유 조각도 직접 설정한다. 2/3, 3/5(권장), 4/7 방식 중 하나로 비밀 정보를 나눠 신뢰하는 사람이나 별도 저장소에 보관할 수 있다. 모든 조각과 암호화된 시드 묶음이 든 복구 파일도 내려받을 수 있다. 이 파일 하나로 계정을 복구할 수 있으며, 선택적으로 최소 20자 암호문구로 보호한다.
기본적으로 계정 비밀 정보로 로그인하지만, 사용자는 브라우저가 계정을 기억하게 하거나 FIDO2 보안 키·패스키(uID)를 등록할 수 있다. 기억한 브라우저는 PIN을 요구하는 방식(90일)과 바로 로그인하는 방식(30일) 중 하나다. PIN을 열 번 연속 틀리면 다시 세 비밀 정보로 로그인해야 한다. 기기와 서버 데이터베이스를 함께 탈취하면 PIN 방식은 오프라인 추측에 노출될 수 있다. 바로 로그인 방식에서는 만료되거나 해제될 때까지 기기 자체가 계정 접근 수단이 된다.
uID는 WebAuthn PRF 기능을 지원해야 하며, 사용자 확인 뒤 인증기가 계산한 값으로 시드 묶음을 푼다. 등록에는 계정 PIN이 필요하고 계정당 최대 열 개까지 둘 수 있다. 지원되지 않는 인증기나 PRF 값을 반환하지 않는 패스키 저장소는 거부한다. 동기화 패스키는 동기화 계정의 보안 수준에 의존하며, 현재 조직은 uID 사용을 요구할 수 있어도 하드웨어 보안 키만 따로 강제할 수는 없다. uID 서명 자체는 Ed25519·ECDSA P-256·RSA 등 기존 방식이지만, 일회성 로그인 요청을 인증할 뿐 콘텐츠를 보호하지 않는다.
콘텐츠는 무작위 콘텐츠 키로 암호화하고, 읽을 권한이 있는 사람마다 키를 따로 감싼다. 파일·문서·스프레드시트·프레젠테이션·보드·프로젝트·일정은 리소스별 키를 쓴다. 접근 권한을 취소하면 소유자 기기가 새 키로 내용을 다시 암호화하고 남은 사용자에게만 키를 제공한다. 서버는 이전 키 버전으로 저장이나 공동 편집을 시도하는 요청을 거부한다. 다만 권한이 취소된 사람이 이전에 복사한 내용은 회수할 수 없다. 채팅·메일·알림은 수신자별 사본을 만들고, 구성원 전체가 보는 게시물은 워크스페이스 키를 쓴다.
uOS는 ML-KEM과 X25519, ML-DSA와 Ed25519를 결합해 두 방식이 모두 성공해야 암호화와 서명이 성립하도록 설계했다고 밝힌다. 대칭 암호에는 256비트 키의 XChaCha20-Poly1305를 쓴다. v2는 ML-KEM-768·ML-DSA-65를 사용하며 업그레이드 전 계정에만 허용된다. uos.sh는 2026년 9월부터 새 키에 v3-hybrid(ML-KEM-1024, ML-DSA-87, Ed25519)를 쓴다. 전용 설치용 v3-cnsa도 구현돼 있지만, 첫 전용 설치는 앞으로 진행할 단계다. 합성 암호 구성이 uOS 자체 설계이며 IETF 표준과의 정렬은 로드맵에 있다.
서버에 보이는 정보와 조직 기능
암호화는 서버가 모든 정보를 보지 못하게 하지는 않는다. 서버는 대화·워크스페이스·회의 구성원, 활동 시각, 메일 발신자와 수신자, 파일 공유 관계와 폴더 구조, 일정 시작·종료 시각, AI 모델 선택 등을 볼 수 있다. 채팅은 저장된 발신자 정보를 없애지만 서버는 메시지를 제출한 로그인 세션과 시각, 대화 구성원을 안다. 파일 크기는 2의 거듭제곱 단위로 패딩하고 파일 시각은 시간 단위로 낮춘다. 온라인 상태는 메모리에 90초 보관하며, 활동 시각은 24시간, 마지막 접속 정보는 30일 뒤 만료한다.
uMail은 uOS 계정 사이에서만 작동하며 인터넷 이메일 주소와 주고받지 않는다. uMeet는 자체 미디어 라우터와 중계 서버를 쓰고 제3자는 회의에 참여하지 않는다. 영상·음성 프레임은 브라우저에서 AES-256-GCM으로 암호화한다. 새 참가자가 들어오면 발신 키를 갱신해 이전 발언을 들을 수 없게 하고, 참가자가 나가거나 퇴장당해도 새 키를 쓴다. 회의는 최대 50명이며, 계정 없는 초대 손님은 호스트가 입장시켜야 한다. 손님 신원은 검증되지 않고, 입력한 이름만 표시된다.
조직 워크스페이스에는 역할·권한, 소유자 정족수 승인, 감사 기록, 보존 규칙, 다운로드 제한, 워터마크, 소송 보존, 외부 조직 계정으로 보내는 메일 통제 기능이 있다. 조직은 업무 자료를 복구하기 위해 에스크로 키를 만들 수 있다. 키는 생성한 소유자의 브라우저에서 만들어지고, 지정된 소유자와 담당자에게 나눠 암호화한다. 복구에는 정족수의 참여가 필요하며 서비스 운영자는 조각을 갖지 않는다. 에스크로는 조직 플랫폼에서 선택된 파일·문서·스프레드시트·보드·일정·노트·할 일·메일에만 적용되고, 개인·협업 플랫폼과 직접·그룹·비밀 채팅에는 적용되지 않는다. 적용되는 항목에는 조직이 복구할 수 있다는 표시가 나온다.
조직은 uID로 로그인한 세션만 플랫폼을 열 수 있게 설정할 수도 있다. 이 정책은 서버가 세션의 uID 사용 여부를 확인해 접근을 거부하는 규칙이지, 암호학적 장벽은 아니다. 침해된 서버가 규칙을 우회할 수 있고, 구성원은 이미 브라우저에 있는 키를 계속 보유한다. 조직 정책 변경은 감사 기록에 남는다.
AI와 한계
AI 대화·추론 기록·도구 결과·첨부 파일은 사용자의 키로 종단간 암호화해 저장한다. 그러나 답변을 생성할 때 관련 문맥은 선택한 모델 제공업체에 평문으로 전달된다. 서비스는 요청 내용을 저장하거나 기록하지 않는다고 설명하지만, 이는 서버 소프트웨어의 동작에 관한 것으로 암호학적 보장은 아니다. 서버가 침해되면 요청 문맥을 기록할 수 있다. 사용자와 조직 모두 AI 전송을 허용해야 요청이 처리되며, 로컬 모델을 Desktop Agent로 실행하면 문맥이 기기 밖으로 나가지 않는다.
Desktop Agent는 사용자가 허용한 경로와 명령만 다루며, 파일 쓰기·삭제·명령 실행 등은 브라우저에서 정확한 작업을 승인해야 한다. 사용자는 한 AI 요청 동안 특정 유형의 작업을 자동 승인하거나, 탭에서 시작하는 모든 AI 요청에 대한 자동 승인을 켤 수 있다. 자동 승인은 탭 메모리에만 보관된다. 시작 프로그램 파일 수정은 항상 확인을 요구하고, 차단 패턴이나 브라우저가 내용을 읽을 수 없는 작업은 거부한다. 다만 서버가 침해되면 작업 디렉터리 안의 읽기 전용 도구를 실행할 수 있으며, 사용자가 자동 승인을 켠 동안 승인된 종류의 작업을 AI 요청에 추가할 가능성이 있다.
제작자가 밝힌 주요 한계는 다음과 같다. uOS는 알파이며 독립 보안 감사가 아직 없다. 구형 계정은 다음 로그인 전까지 이전 방식의 키를 쓰고, 과거에 만든 일부 비공개 보드와 게시물은 소유자나 관리자가 다시 열기 전까지 서버에서 읽을 수 있다. 출시 서명과 검증 도구는 있지만 독립 로그에 게시되지 않았고 브라우저가 자동 검증하지 않는다. 모바일 앱은 개발 중이며 현재 v2를 지원하므로 휴대전화에서는 웹 앱이 지원 경로다. 공개 프로필은 제품 설계에 따라 서버가 읽을 수 있다. 서버 소스는 공개되지 않았고, 클라이언트 저장소도 현재 비공개이며 보안 전문가·감사자·연구자가 요청하면 열람할 수 있다. 제작자는 베타 이후 저장소를 공개할 계획이라고 밝혔다.
서비스 침해나 법적 요구가 있어도 운영자가 가진 것은 암호문과 메타데이터이며, 조직 에스크로 자료는 조직 담당자 정족수만 복구할 수 있다는 것이 uOS의 위협 모델이다. 반면 악성 클라이언트 전달, 메타데이터 노출, 키 투명성 로그가 사용자별로 다르게 제시되는 경우, 오프라인 비밀 정보 추측, 기기 침해와 서비스 가용성 문제는 완전히 제거되지 않는다. 특히 브라우저 앱을 불러오는 순간 TLS를 통제하는 공격자는 다른 코드를 전달할 수 있다. 사용자가 출시 파일을 직접 검증하지 않으면 그 방문에서 보호받지 못할 수 있다.
자세한 암호 프로토콜·애플리케이션별 서버 가시성·위협 모델은 uOS 저장소에 연결된 기술 문서에 제시돼 있다. 저장소는 현재 비공개이며, 제작자는 소스 제공 방식이고 오픈소스는 아니라고 설명한다. uOS는 개인에게 무료로 제공하고 광고·데이터 판매·행동 프로파일링에 의존하지 않으며, 조직에는 좌석 단위로 과금할 계획이다. 알파 기간에는 구조화된 피드백을 제공하는 조직이 무료로 이용할 수 있다.
부록: 원문 예시
PRF_INPUT = SHA-256("uOS/uid/prf/v1") fixed for every credential
prf = WebAuthn PRF(credential, PRF_INPUT) inside the authenticator, after user verification
K = HKDF-SHA256(prf, salt = cred_salt₃₂, info = "uOS/uid/v1" ‖ credential id)
box = XChaCha20-Poly1305(K, nonce₂₄, account id ‖ seed bundle, AAD = "uOS/uid/bundle/v1|" ‖ credential id)
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요