jaysnote
9분

Apple은 요청을 온디바이스↔클라우드로 어떻게 나누나 — 분석과 그 한계

Apple Intelligence가 요청을 온디바이스와 Private Cloud Compute로 분기하는 메커니즘을 리버스 엔지니어링 분석(arXiv 2605.24239)으로 짚되, 무엇이 밝혀지지 않았는가를 먼저 분명히 합니다. 데몬 흐름·TGT/OTT 토큰·검증, 발견된 구현 허점까지.

#Apple #PrivateCloudCompute #온디바이스AI #보안 #프라이버시

앞서 AFM 3 Core Advanced 글에서 “무거운 요청은 Private Cloud Compute(PCC)로 넘어간다”고 했습니다. 그럼 어떤 요청이 온디바이스에 남고 어떤 요청이 클라우드로 가는지, 그 판단은 어떻게 이뤄질까요. 보안 연구자들의 리버스 엔지니어링 분석을 바탕으로 정리하되, 결론부터 — 정작 가장 궁금한 “판단 기준”은 아직 밝혀지지 않았습니다.

먼저: 이 분석의 한계 (서두에 분명히)

이 글의 근거는 대부분 Apple 공식 문서가 아니라 리버스 엔지니어링 분석(arXiv 2605.24239 등)입니다. 그래서 무엇이 밝혀졌고 무엇이 안 밝혀졌는지를 먼저 못 박습니다.

무엇이 밝혀졌고 무엇이 안 밝혀졌나

밝혀진 것

  • 요청이 거치는 데몬 체인과 순서
  • “로컬 우선, 로컬이 못 하면 PCC” 라는 원칙
  • PCC로 갈 때의 TGT/OTT 2단 토큰 + OHTTP 릴레이 전송
  • 노드 신뢰 근거인 cloud attestation · transparency log

밝혀지지 않은 것 (핵심 한계)

  • modelmanagerd가 “처리 가능”을 판정하는 내부 기준 — 임계값·신뢰도·요청 분류가 문서화되지 않음. 논문도 “the document does not specify what ‘handle’ means mechanically — no thresholds, confidence scores, or request types are documented.” 라고 명시.
  • 전체 소스 미공개 + 빌드 재현 불가 → 배포 바이너리가 명세와 같은지 검증 불가.
  • 릴레이 신뢰·데이터 삭제 보장은 제3자 감사 없이는 확인 불가.
  • 전부 OS 버전 의존적이며 Apple 공식 명세와 다를 수 있음.

한 줄로: “어디서 처리되나”의 흐름은 알지만, “왜 그렇게 나뉘나”의 알고리즘은 여전히 블랙박스.

1. 기기 안의 요청 파이프라인 — 4개 데몬

분기 자체는 기기 안에서 먼저 일어납니다. 요청이 거치는 데몬 순서가 분석으로 드러났습니다.

온디바이스 요청 파이프라인 — 4개 데몬

  1. generativeexperiencesd — 요청의 “first point of contact”(최초 수신).
  2. modelmanagerd — 로컬 vs PCC 분기 결정. 백그라운드에서 일어나고 사용자에게 표시되지 않음.
  3. privatecloudcomputed — PCC로 갈 경우 클라우드 요청을 오케스트레이션.
  4. networkserviceproxy — 키체인에서 인증 토큰을 관리·획득.

핵심 문장: “Only if the local models cannot handle a request type is it forwarded to privatecloudcomputed.” — 기본은 로컬, 안 될 때만 클라우드. 다만 앞서 말했듯 “handle 가능”의 판정 기준 자체는 이 데몬 안에 가려져 있습니다.

2. 클라우드로 갈 때 — TGT/OTT 2단 토큰

PCC로 넘어가면 두 종류의 토큰으로 권한을 증명합니다.

TGT/OTT 토큰 흐름

  • TGT (Token Granting Token): 사용자·기기마다 1개. 자격 증명용. 신원과 연결 불가(unlinkable).
  • OTT (One-Time Token): Token Granting Service에서 배치로 발급. 개별 요청용.

OTT 획득(소진/만료 시): 기기가 TGT를 제시 → Token Granting Service가 TGT 유효성 검사 → OTT 배치 반환. 이 서비스는 OHTTP 릴레이 뒤에 있어, TGT는 신원과 연결되지 않고 릴레이가 IP를 가립니다.

실제 요청: 기기가 (요청 + TGT)를 암호화하고 OTT(평문)를 권한 증명으로 첨부 → OHTTP 릴레이 경유(3rd-party 릴레이는 IP만 보고 내용은 복호화 못 함) → PCC Gateway가 OTT 검증 → PCC Node가 복호화 후 TGT 검사, 유효해야만 처리·응답. PCC 노드는 복호화하지만 원본 IP는 못 봅니다(관심사 분리).

3. 노드를 믿는 근거 — 검증(attestation)

기기는 검증된 노드에만 데이터를 보냅니다.

검증(attestation)

  • Cloud attestation: Apple이 클라우드 소프트웨어 바이너리 이미지를 공개 → 연구자가 VRE(PCC Virtual Research Environment) 에서 같은 소프트웨어를 돌려 일치 확인.
  • Transparency log: 기기가 투명성 로그로 클라우드 소프트웨어 상태를 대조한 뒤 신뢰.
  • OHTTP: IP와 내용을 분리해, 한 주체가 둘을 함께 보지 못하게 함.

4. 논문이 찾은 실제 구현 허점 5가지

여기가 이 분석의 핵심 가치입니다. 문서상 보장과 모순되는 구현 결함이 실증됐습니다.

발견된 구현 허점 5가지

  1. 토큰 검증 우회 — Challenge·Public Key ID가 틀리면 거부하지만, Token Type·Nonce·Signature 필드는 바꿔도 통과. “서명 검증한다”는 소스 주장과 모순.
  2. OTT 재사용 — 이름은 “One-Time”인데 같은 OTT를 2~5회 재사용해도 응답이 옴.
  3. 타 기기 토큰 수용 — 다른 Mac의 TGT·OTT로 바꿔치기해도 동작. “OTT는 TGT에서 파생”이라는 요건과 모순.
  4. 메타데이터 연결성 — per-token salt 때문에 TGT+salt+OTT를 가진 공격자가 요청들이 한 묶음임을 연결 가능. 암호화에도 불구한 프라이버시 노출.
  5. 레이트리밋이 단일 신뢰점 — 같은 계정·기기로 TGT를 연속 6개까지 발급 가능(그 뒤 제한). 신뢰 경계가 얇음.

5. 끝까지 확인할 수 없는 신뢰 가정

암호학으로 강제되지 않고 결국 “믿어야” 하는 부분도 논문이 지목했습니다.

검증 불가능한 신뢰 가정

  • 릴레이 운영자 신뢰: “Apple과 릴레이 간 IP 정보 미교환”은 제3자 감사 없이는 검증 불가.
  • 데이터 삭제: 요청 삭제는 소프트웨어로 구현 — “a node cannot be forced to forget requests solely through cryptographic protocol measures.” 암호학적으로 강제되지 않음.
  • 소스-바이너리 일치: 전체 소스 미공개 + 빌드 재현 불가 → 배포 바이너리가 명세와 같은지 확인 불가.

정리

  • 분기 주체·순서는 명확: generativeexperiencesd 수신 → modelmanagerd가 로컬 vs PCC 결정 → 로컬 우선, 못 하면 privatecloudcomputed로 위임.
  • 분기 기준은 비공개: 임계값·요청 분류는 리버스 엔지니어링으로도 드러나지 않았고, 공개적으로 확립된 건 “로컬 모델 능력 + 작업 복잡도” 라는 정성적 원칙뿐.
  • 전송·검증은 잘 설계(TGT/OTT + OHTTP + attestation)됐지만, 그 구현에서 여러 우회 결함이 발견됐고 검증 불가능한 신뢰 가정도 남는다.
  • 무엇보다 이 모든 건 리버스 엔지니어링 분석이라, OS 버전에 따라 다르고 Apple 공식 명세와 어긋날 수 있다.

결국 “요청을 어떻게 나누나”에 대한 가장 정직한 답은 이것입니다 — 흐름과 보안 계층은 상당히 밝혀졌지만, 정작 분기를 결정하는 판단 로직 자체는 아직 공개되지 않았다.

출처

관련 글

← 목록으로