다른 기기를 통해 활성화
인터넷에 연결되지 않은 앱은 요청 파일과 활성화 응답을 다른 PC로 옮겨 인증할 수 있어요. 고객 계정과 라이센스는 브라우저로 활성화할 때와 같고, 요청과 응답을 전달하는 방법만 달라요.
활성화 응답은 승인한 기기에서만 열 수 있도록 보호돼요. 먼저 앱이 실행될 환경에서 기기 보호 기능을 사용할 수 있는지 확인하세요.
실행 환경 준비하기
섹션 제목: “실행 환경 준비하기”SDK는 OS에 맞는 실행 모듈을 선택해요. 일반 앱 코드에서 장치 공급자 이름이나 키 정보를 직접 조립하지 마세요.
| 환경 | 실행 모듈·필요 조건 | 현재 검증 범위 |
|---|---|---|
| Linux | Python 3, tpm2-tools, TPM 2.0 리소스 매니저와 기기 접근 권한 | Linux 실물 장치와 시뮬레이터에서 파일 교환·서명 검증을 확인했어요. |
| Windows | Windows 10/11, Windows PowerShell 5.1, 준비된 TPM 2.0과 Microsoft Platform Crypto Provider | Windows 러너에서 플랫폼 키 생성·재사용·서명·복호화·잘못된 대상 거부를 확인했어요. |
| macOS | macOS 11+, Secure Enclave 지원 기기, 보호 키 핸들을 보존할 개인 상태 디렉터리 | Apple Silicon Mac에서 보호 키 연산을 확인했어요. arm64·x86_64 바이너리를 빌드하며 Intel 실장비 검증은 별도예요. |
Mac SDK 0.3.1 패키지에는 범용 네이티브 실행 파일이 포함되어 일반 실행에 Swift·Xcode가 필요하지 않아요. 상태 디렉터리에 저장하는 것은 비밀키 평문이 아니라 Secure Enclave가 감싼 기기 전용 핸들이에요. 일반적인 이동 가능한 개인키처럼 사용하지 말고 원래 기기에서 보존하세요.
외부 앱 배포에서는 공급자의 앱에 맞게 실행 파일 서명·공증을 적용하고 최종 배포물을 검증하세요.
소프트웨어 RSA/ECDH 테스트가 성공해도 실제 OS의 보호 저장소에서 동작한다고 확인된 것은 아니에요. 보호 기능이 없거나 접근할 수 없는 기기에서는 온라인 활성화와 통신 유예를 사용해요. USB 토큰 모듈은 아직 제공하지 않아요.
운영자의 기기 신뢰 등록
섹션 제목: “운영자의 기기 신뢰 등록”보호된 응답을 발급하려면 해당 기능을 제공하는 요금제와 기기 키의 신뢰 등록이 필요해요. 운영자는 실제 기기에서 공식 실행 모듈이 보호 저장소를 사용해 생성한 공개키를 별도 신뢰 경로로 대조한 뒤, 운영자 보안 화면의 기기 보호 키 신뢰 등록에서 등록하세요.
고객이 보내온 요청의 provider 이름만으로 하드웨어 키임을 판단하지 마세요. 제조사 인증서 검증은 자동으로 제공하지 않아요. 앱 사용자에게 장치 종류를 고르게 하는 대신, 공급자가 지원 환경과 신뢰 등록을 준비해야 해요.
1. 원래 앱에서 요청 파일을 만드세요
섹션 제목: “1. 원래 앱에서 요청 파일을 만드세요”사용하는 언어의 샘플을 설치한 뒤 activation-request request.signox를 실행하세요. 샘플이 SDK의 createRequest() 또는 언어별 대응 메서드로 공개 요청을 만들고 파일로 저장해요.
요청 파일에는 승인할 제품과 기기의 공개 정보가 들어 있어요. 요청 자체는 이용권이 아니에요. 결과를 받기 위한 비밀과 설치 자격증명은 앱의 개인 상태 디렉터리에 남겨 두세요.
정상 결과는 request.signox 파일이 생성되는 거예요. 같은 앱에서 명령을 반복하면 기존 요청을 재사용해요. 요청의 7일 유효기간이 지났다면 샘플의 activation-renew-request request.signox로 새 요청을 만드세요.
2. 연결된 PC의 고객 포털에 요청을 가져오세요
섹션 제목: “2. 연결된 PC의 고객 포털에 요청을 가져오세요”고객 포털 /activate를 열고 요청 파일을 선택하거나 요청 코드를 붙여넣으세요. 포털이 요청의 제품을 조회한 뒤 해당 앱의 이름과 로고를 보여줘요.
앱 이름이 맞는지 확인하고 고객 계정으로 로그인하세요. 벤더 대시보드 계정은 고객 계정과 달라요. 소유한 라이센스가 없다면 구매 키를 먼저 등록하세요.
3. 라이센스를 선택하고 응답을 받으세요
섹션 제목: “3. 라이센스를 선택하고 응답을 받으세요”사용할 라이센스와 기기 이름을 확인하고 이 기기 활성화를 누르세요. 확인창에서 승인하면 응답이 발급되고 이 기기에 등록이 예약돼요.
- 이미 다른 기기에 등록되어 있으면 기기 이전 요청으로 안내해요. 사유를 입력하면 벤더가 해당 목적지 요청을 검토해요.
- 신뢰 등록이 필요하다고 나오면 공급자가 실제 기기의 공개키를 대조·등록한 뒤 다시 승인해야 해요.
- 만료·정지·폐기된 라이센스는 연결 장애로 간주하지 않아요. 이용권 상태부터 해결해야 해요.
활성화 파일 저장으로 activation.signox를 내려받으세요. 발급됨은 실제 기기에 적용됐다는 의미가 아니에요.
4. 원래 기기에 응답을 적용하세요
섹션 제목: “4. 원래 기기에 응답을 적용하세요”activation.signox를 원래 기기로 옮기고 샘플의 activation-apply activation.signox를 실행하세요. SDK는 응답 서명·제품·요청·기기 일치를 확인하고, 기기가 보관한 키로 응답을 연 뒤 기간과 기능 권한을 검증해요.
요청과 응답을 한 번씩 옮기면 돼요. 앱 개발자가 중간 challenge/proof 파일을 교환하는 구형 절차는 사용하지 않아요.
정상이라면 VALID 또는 IN_GRACE_PERIOD와 valid=true가 나와요. 실제 기능을 실행할 때는 필요한 기능값도 확인하세요. ACTIVATION_RESPONSE_INVALID가 나오면 응답이 해당 요청·제품·기기의 것인지 확인하고 파일을 수정하지 않은 상태로 다시 적용하세요.
적용 확인과 기기 이전 이해하기
섹션 제목: “적용 확인과 기기 이전 이해하기”연결된 앱은 적용 확인을 서버로 보낼 수 있어요. 연결되지 않은 앱의 적용 여부는 포털에서 자동 확인할 수 없으므로 발급 상태로 남을 수 있어요.
같은 보호 키가 남아 있으면 같은 기기의 등록을 복구할 수 있어요. Windows의 키 저장소나 Mac의 기기 전용 보호 키 핸들까지 지워지면 기기 이름이 같더라도 기존 키를 복구했다고 판단하지 않아요. 이 경우에는 새 요청으로 이전 검토를 받아야 해요.
완전 오프라인 기기에는 원격 정지·폐기 신호를 즉시 보낼 수 없어요. 파일 삭제나 포맷도 옛 백업이 중단됐다는 증명이 아니에요. 벤더의 예외 이전 승인은 이 불확실성을 확인하는 절차이며 물리적인 중복 사용이 전혀 없음을 증명하지 않아요.