온디바이스 모델 암호화가 API 인증을 대체할 수 없는 이유

모바일 AI 애플리케이션을 7 가지 자산 클래스로 분해

모바일 AI 보안은 종종 모델 암호화 여부로 단순화되지만, 실제 공격 표면에는 모델 파일, 추론 런타임, 입력 전처리, 출력 후처리, 프롬프트 또는 비즈니스 규칙, 원격 API 자격 증명, 사용자 데이터, 로그가 최소한 포함됩니다. 각 자산 클래스는 유출 시 서로 다른 결과를 초래하며, 업데이트 메커니즘과 소유 책임도 각각 다릅니다.

모델 가중치 복제는 지적 재산권 탈취와 비즈니스 역량 상실로 이어질 수 있으며, 프롬프트 템플릿이나 후처리 로직 변조는 비즈니스 동작을 변경할 수 있습니다. 장기간 유효한 API 키 유출은 금전적 손실, 무단 데이터 접근, 자원 남용으로 직결될 수 있고, 입출력 로그에는 사용자 개인정보가 포함될 수 있습니다. 모델 파일만 보호해서는 이러한 잔여 위험을 모두 커버할 수 없습니다.

자산 등록부는 저장 위치, 생성 소스, 전송 경로, 런타임 사용 패턴, 업데이트 및 롤백 메커니즘, 최소 권한 원칙, 로그 범위 및 보존 기간을 문서화해야 합니다. 정의된 수명 주기가 없는 자산은 암호화 스위치 활성화만으로 보호된 것으로 간주해서는 안 됩니다.

모델 파일은 런타임 동안 사용 가능한 자료가 되어야 함

Core ML, LiteRT 또는 기타 온디바이스 (On-device) 런타임을 사용하는지와 관계없이 모델은 로드, 파싱되어 연산에 참여해야 합니다. 파일 계층 암호화는 설치 패키지나 앱 디렉터리에서의 직접 복사를 어렵게 만들지만, 실행 중인 애플리케이션이 모델 자료에 접근하는 것을 방지할 수는 없습니다. 공격자가 프로세스를 제어하거나 런타임을 관찰할 수 있다면, 위험 모델은 정적 파일에서 로딩, 메모리, 함수 호출 (Invocation) 및 출력으로 이동합니다.

이것이 모델 암호화의 가치를 부정하는 것은 아닙니다. 저비용 복제를 어렵게 하고 직접 대체를 방지하며, 패키지 보호, 무결성 검사, 런타임 환경 감지, 버전 페어링과 함께 심층 방어 전략의 일부를 구성합니다. 핵심은 추출이 불가능하다고 주장하기보다 공격 비용을 높이고 노출 면적을 줄이는 데 초점을 맞추는 것입니다.

모델 업데이트는 호환성 문제도 발생시킵니다. 모델 버전은 전처리 로직, 특성 형태 (feature shapes), 런타임 버전, 하드웨어 성능, 후처리 규칙과 정확히 쌍을 이루어야 합니다. 업데이트 실패 시 구형 모델과 신형 로직이 무작위로 결합되는 것을 방지하기 위해 안전한 롤백이 필요합니다.

장기 고권한 API 키는 클라이언트 기밀로 사용해서는 안 됩니다

Android 보안 문서는 소스 코드에 내장된 API 키가 앱 컴파일 후 역컴파일을 통해 발견될 수 있다고 명시합니다. 난독화와 애플리케이션 강화 (application hardening) 는 키 위치 파악 비용을 높일 수 있지만, 클라이언트가 이러한 자격 증명을 보유하고 사용해야 한다는 사실 자체는 바꾸지 못합니다. 키가 범용 클라이언트 내에서 장기적이고 고권한 상태로 유지되는 한, 유출 시 영향을 제한하기 어렵습니다.

Android Keystore 는 특정 키 소재를 내보낼 수 없도록 보호하지만, 공식 문서에 따르면 애플리케이션 프로세스가 침해될 경우 공격자가 앱의 키를 사용하여 연산을 수행할 가능성이 있다고 명시합니다. 이는 디바이스 바인딩된 개인 키와 로컬 암호화 보호에는 적합하지만, 원격 서비스를 위한 임의의 장수명 공유 비밀을 저장하는 안전한 금금고로 오해해서는 안 됩니다.

보다 견고한 아키텍처를 위해서는 클라이언트가 사용자 신원과 디바이스 컨텍스트에 기반하여 자체 서비스로부터 단명하며 제한되고 취소 가능한 토큰을 요청하거나, 서버 사이드 프록시가 고위험 모델 호출을 처리하도록 해야 합니다. 서버는 계정 권한 부여, 할당량, 속도 제한, 모델 범위, 데이터 범위 및 이상 행동 모니터링을 반드시 강제해야 합니다.

• 개발, 테스트, 운영 환경별로 자격 증명을 격리하십시오
• 토큰이 최소한의 모델 및 데이터 권한만 갖도록 보장하십시오
• 서버 사이드 취소를 활성화하고 할당량 및 속도 제한을 강제하십시오
• 클라이언트가 장수명 고권한 공유 키를 저장하지 못하도록 방지하십시오

request = verify_user_session(input.session)
app = verify_app_evidence(input.attestation)
policy = load_policy(user=request.user, app=app.identity)

if policy.version_state == UNKNOWN:
    return CHALLENGE_OR_LIMIT
if policy.account_scope.allows(input.model_scope) == false:
    return DENY
if policy.risk_score >= HIGH:
    return STEP_UP_VERIFICATION

return issue_short_lived_token(
    scope=input.model_scope,
    quota=policy.quota,
    expires_in=policy.short_window
)

무결성 신호는 서버 사이드 결정에만 참조되어야 합니다

Play Integrity 는 Android 백엔드에 앱 식별, 디바이스 무결성, 계정 라이선싱 및 부분적인 환경 위험에 관한 신호를 제공합니다. Apple App Attest 는 디바이스 키 생성, 일회용 챌린지 발급, 서버에서의 증명 검증 및 후속 어설션 처리를 통해 서버가 요청이 유효한 앱 인스턴스에서 originated 되었는지 판단하도록 지원합니다. 두 방식의 공통점은 증거가 궁극적으로 서버에서 검증된다는 점입니다.

이러한 메커니즘은 명확한 한계를 가집니다. Play 관련 신호는 배포 소스, 디바이스 상태 및 서비스 조건에 영향을 받으며, Apple 문서에서는 App Attest 가 모든 디바이스 유형에서 지원되지 않으며 단일 정책으로 모든 사기를 제거할 수 없다고 명시합니다. 서버는 통과, 실패, 사용 불가, 일시적 오류 및 미구성 상태를 구분해야 합니다. '사용 불가' 상태를 직접 공격으로 간주해서는 안 되며, 클라이언트 측에서 최종 판단을 수행해서도 안 됩니다.

무결성 신호와 모델 암호화는 서로 다른 문제를 해결합니다. 전자는 애플리케이션 인스턴스와 런타임 환경을 검증하는 데 도움이 되며, 후자는 정적 모델 노출을 줄입니다. 진정한 권한 부여에는 여전히 계정 컨텍스트, 비즈니스 리소스 검사, 버전 유효성 검증, 요청 콘텐츠 분석, 할당량 강제 적용 및 행동 컨텍스트가 필요합니다.

모바일 AI 애플리케이션 검증에는 정적, 런타임 및 서버 측 관점이 모두 필요함

정적 검사는 설치 패키지에 어떤 모델, 구성, 문자열, 자격 증명 및 디버그 리소스가 존재하는지 답변하며, 런타임 검사는 모델이 어떻게 로드되는지, 오류가 어떻게 처리되는지, 로그가 데이터를 유출하는지, 업데이트가 롤백 가능한지 답변합니다. 서버 측 검사는 계정, 버전, 무결성, 할당량 및 데이터 권한이 실제로 강제 적용되는지 답변합니다. 이 세 가지 증거 유형 중 하나라도 누락되면 결론이 부분적인 관점으로 치우치게 됩니다.

테스트는 고유한 릴리스 후보 버전과 명시적인 모델 버전을 사용해야 하며, 대상 시스템, 디바이스 기능, 런타임 백엔드, 모델 소스 및 업데이트 상태를 문서화해야 합니다. 온디바이스 추론 성능, 메모리 사용량 및 호환성은 모델 구조, 양자화, 하드웨어 및 런타임에 따라 달라지므로 다른 모델이나 디바이스의 수치를 인용해서는 안 됩니다.

예외 경로가 중요합니다. 모델 파일 누락 또는 손상, 업데이트 중단, 지원되지 않는 런타임, 만료된 서버 토큰, 사용 불가능한 무결성 신호, 로그 업로드 실패 및 사용자 권한 취소 등이 해당됩니다. 시스템은 안전하게 성능을 저하시켜 사용자와 운영 팀 모두에게 복구 가능한 상태를 제공해야 합니다.

설계 결론 및 범위 제한사항

모델 암호화는 가치가 있으나 모델 수명 주기 내 단일 제어 지점에 불과합니다. 상업용 AI 애플리케이션은 전처리 및 후처리 로직을 보호하고, 장기 존속 고권한 키가 클라이언트로 유입되는 것을 방지하며, 서버에서 최종 권한 부여를 수행하도록 하고, 플랫폼 무결성 신호에 대한 내결함성을 구현하며, 사용자 데이터와 로그를 거버넌스해야 합니다.

실제 릴리스 후보, 모델 버전, 대상 기기 및 서버 측 인터페이스가 없으면 아키텍처와 검증 대기 항목만 검토 가능합니다. 모델 추출 방지, 인터페이스 남용 방지, 런타임 인젝션 차단 또는 성능 목표 달성을 주장할 수 없습니다. 이러한 결론에는 현재 시점의 증거 패키지가 필수적입니다.

본 페이지의 Yudun 액션 진입점은 애플리케이션 강화 및 호환성 평가를 신청하기 위한 것이며, 특정 모델 프레임워크나 AI 전용 기능의 검증을 의미하지는 않습니다. 프로젝트 범위는 기술 스택, 모델 전달 방식 및 핵심 비즈니스 경로를 제출한 후 별도로 확정해야 합니다.

• 모델, 런타임, 자격 증명 및 데이터에 대해 별도의 레지스터를 유지 관리
• 고위험 함수 호출에 대한 최종 권한 부여가 서버에서 수행되도록 보장
• 플랫폼 신호 사용 불가 시를 대비한 대체 경로 및 기능 저하 경로 제공
• 모델 업데이트가 검증, 원자적 전환 및 롤백을 지원하도록 활성화
• 모든 결론을 특정 릴리스 후보 및 모델 버전에 연계