어제, 오늘 그리고 내일

공동 인증서(구 공인인증서)에서 주체키와 기관키는 암호학적인 공공키 기반 구조(PKI, Public Key Infrastructure)에서 중요한 역할을 합니다. 이 두 키의 관계는 다음과 같습니다

#1. 주체키와 기관키 정의

1. 주체키 (Subject Key):
   • 주체키는 인증서의 주체, 즉 인증서 소유자(개인 또는 기업)가 보유한 개인키(Private Key)와 공개키(Public Key)를 의미합니다.
   • 인증서 소유자는 개인키를 비밀로 유지하며, 공개키는 인증서에 포함되어 누구나 접근할 수 있습니다.
   • 주체키는 주로 전자서명, 데이터 암호화/복호화 등에 사용됩니다.
   • 공개키와 개인키는 쌍으로 이루어져 있으며, 개인키로 서명한 데이터를 공개키로 검증할 수 있습니다.
2. 기관키 (CA 키, Certificate Authority Key):
   • 인증 기관(CA, Certificate Authority)은 인증서를 발급하는 기관으로, 기관키는 해당 기관이 사용하는 개인키와 공개키를 의미합니다.
   • 인증 기관의 공개키는 누구나 접근할 수 있으며, 이를 통해 인증 기관이 발급한 인증서를 검증할 수 있습니다.
   • 인증 기관의 개인키는 비밀로 유지되며, 이 키를 사용하여 인증서에 서명합니다. 즉, 인증 기관이 발급하는 인증서는 CA의 개인키로 서명되어 있으며, 누구나 CA의 공개키로 이 서명을 검증할 수 있습니다.

관계 요약:

• 주체키는 인증서 소유자의 공개키/개인키 쌍을 의미하고, 기관키는 인증서를 발급하는 CA의 공개키/개인키 쌍을 의미합니다.
• 인증서를 사용할 때, 인증서에 포함된 주체의 공개키는 인증 기관의 서명(기관의 개인키로 서명됨)을 통해 신뢰성을 검증받습니다. 즉, 기관키는 주체키의 유효성을 검증하는 역할을 하며, 이 과정에서 인증 기관이 신뢰할 수 있는지를 보장해 줍니다.

이런 구조를 통해 PKI는 전자서명과 인증서의 신뢰성을 유지하며, 안전한 통신 환경을 제공합니다.

#2. 체인 검증

공동인증서에서 주체키와 기관키는 신뢰할 수 있는 인증 체계(PKI)를 통해 검증됩니다. 이 과정에서 체인 검증(Certificate Chain Validation)이 이루어지며, 주체키의 유효성과 신뢰성을 인증하는 중요한 단계입니다. 이 체인 검증은 다음과 같은 절차를 따릅니다.

1. 인증서 체인의 개념

• 인증서 체인은 여러 인증 기관(CA)의 인증서가 계층적으로 연결된 구조입니다. 일반적으로 **루트 인증서(CA)**부터 **중간 인증서(CA)**를 거쳐 **최종 사용자 인증서(End-entity Certificate)**까지 이어집니다.
• 최종 사용자 인증서는 공동인증서 소유자의 인증서(즉, 주체의 인증서)이며, 상위 기관의 서명을 통해 신뢰성을 얻습니다.

2. 체인 검증의 과정

인증서 체인 검증은 주체의 인증서가 신뢰할 수 있는 기관에 의해 발급되었는지 확인하는 절차입니다. 이는 다음 단계로 이루어집니다:

1) 주체 인증서 검증

• 주체 인증서는 공동인증서 소유자의 공개키를 포함하며, 상위 CA의 개인키로 서명되어 있습니다.
• 인증서 검증 과정에서, 주체 인증서의 서명이 올바른지, 즉 상위 CA의 공개키로 서명을 검증합니다.
• 이 상위 CA의 공개키는 중간 인증서에 포함되어 있습니다.

2) 중간 인증서 검증

• 상위 CA가 여러 단계일 경우, 중간 인증서가 존재합니다.
• 중간 CA의 인증서는 상위 인증 기관(CA)에 의해 발급되었으며, 상위 CA의 개인키로 서명되어 있습니다.
• 중간 CA의 인증서 서명도 상위 CA의 공개키로 검증됩니다.

3) 루트 인증서 검증

• 체인의 최상단에는 루트 CA 인증서가 있습니다.
• 루트 인증서는 자체 서명(self-signed)된 인증서로, 일반적으로 신뢰할 수 있는 기관에 의해 미리 신뢰 목록에 포함되어 있습니다.
• 이 루트 인증서는 더 이상 상위 인증서가 필요하지 않고, 운영체제(OS)나 브라우저에서 사전에 신뢰할 수 있는 루트 인증서 목록에 포함됩니다.

4) CRL과 OCSP 확인

• 인증서 체인 검증의 마지막 단계에서, 각 인증서가 폐지되지 않았는지 확인하는 절차가 있습니다.
• 이를 위해 CRL(인증서 폐지 목록, Certificate Revocation List) 또는 OCSP(온라인 인증서 상태 프로토콜, Online Certificate Status Protocol)를 사용하여 인증서의 상태를 확인합니다.
• 만약 주체 인증서 또는 중간 인증서가 폐지된 경우, 인증서 체인 검증은 실패합니다.

3. 체인 검증 요약

• 주체키(즉, 주체의 공개키)는 상위 CA에 의해 서명된 주체 인증서를 통해 신뢰성을 가집니다.
• 주체 인증서는 중간 인증서의 서명을 확인하고, 중간 인증서는 루트 인증서의 서명을 확인합니다.
• 루트 인증서는 신뢰할 수 있는 기관이 직접 신뢰하는 인증서이며, 이를 통해 전체 체인의 신뢰성이 보장됩니다.
• 체인 검증 과정에서 각 인증서의 유효성(서명 검증, 폐지 여부 등)을 확인하여, 해당 인증서가 올바르게 사용되고 있는지 확인합니다.

체인 검증 흐름 요약

1. 주체 인증서 → 중간 CA 인증서 → 루트 CA 인증서 순으로 상위 인증 기관이 서명한 내용을 확인합니다.
2. 각 단계에서 상위 기관의 공개키로 하위 인증서의 서명을 검증합니다.
3. 루트 인증서가 신뢰되는 루트 저장소에 있는지 확인합니다.
4. 각 인증서가 폐지되지 않았는지 CRL 또는 OCSP로 확인합니다.

이를 통해 최종적으로 주체 인증서(공동인증서)가 신뢰할 수 있는 인증 기관에 의해 발급되었음을 확인하게 됩니다.

이번 포스팅은 Swift로 개발한 앱을 App Store에서 업로드하기 위해 앱을 빌드 중 발생한 오류에 대하여 알아보도록 하겠습니다. 

목차

1. PLA의 정의

2. Unable to process request - PLA Update avaiable 원인

3. Unable to process request - PLA Update avaiable 해결 방법

4. 마무리

#1. PLA의 정의

PLA란 Program License Agreement의 약자로 Apple Developer Program 사용권 계약입니다. 'Apple의 개발자 도구 및 서비스를 사용하거나 Apple 플랫폼에서 소프트웨어를 배포하려면 사용권 계약 및 지침의 해당 약관을 준수해야 합니다.'라고 Apple Developer 페이지(https://developer.apple.com/kr/support/terms/)에 명시되어 있습니다. 따라서 Apple 개발자로서 사용권 계약의 어떠한 조항이 변경이 되었으면 변경된 내용을 확인해 보고 동의해야 소프트웨어를 배포할 수 있습니다. 

#2. Unable to process request - PLA Update avaiable 원인

PLA 정의에서 말씀드린 것처럼 'Apple 플랫폼에서 소프트웨어를 배포하려면 사용권 계약 및 지침의 해당 약관을 준수해야 합니다.'라고 명시가 되었습니다. 하지만 저는 최근에  Apple Store Connect에 방문하여 어떠한 액션을 한 적이 없습니다. 따라서 이번 오류의 원인은 Apple Store Connect에서 변경된 PLA( Program License Agreement)에 동의를 하지 않았기 때문이니 사용권 계약을 검토하고 동의한 후에 앱을 App Store에 배포할 수 있습니다.

#3. Unable to process request - PLA Update avaiable 해결 방법

이번 오류의 원인을 알았으니 해결방법은 아주 간단합니다. Apple Store Connect에 접속해서 변경된 PLA를 검토하고 동의를 진행하면 됩니다. 아래 그림과 함께 따라하시면 아주 쉽습니다.1. App Store Connect(https://appstoreconnect.apple.com/login)에 접속하여 배포할 계정으로 로그인을 합니다.2. 로그인을 하면 아래와 같은 화면을 만나실 수 있습니다.

3. Account 화면에 접속하면 아래와 같이 '프로그램 사용권 계약이 업데이트되었습니다.'라는 메시지가 보이실 겁니다. 변경된 사용권 계약에 동의하기 위해 [계약 검토하기] 버튼을 클릭합니다.

4. 개발자 계정에 동의하는 계약은 영문 버전이 법적 구속력이 있으므로 사용권 계약은 영문으로 표시되며 아래 [동의] 버튼을 클릭합니다.

5. 다시 Apple Store Connect 계정(Account)에 접속하면 프로그램 사용권 계약이 업데이트가 되어 아까와 같은 '  '프로그램 사용권 계약이 업데이트되었습니다.' 라는 메시지가 안 보이실 겁니다.

프로그램 사용권 계약이 업데이가 되서 메시지가 표시되지 않는 것이니 xCode를 재시작한 후 재 빌드해 보면 App Store에 배포하기 위한 앱을 빌드하실 수 있으실 겁니다.

#4. 마무리

앱을 빌드해서 App Store에 배포하려고 하는데 빌드 에러가 나면 많이 당황스럽습니다. 하지만 차분하게 하나 하나 내용을 찾아 문제를 해결하면 다시 똑같은 상황을 만나지 않을 뿐더러 쉽게 문제를 해결하실 수 있으실 겁니다.

오늘도 즐거운 개발이 되시길 바라며 긴 글 읽어 주셔서 감사합니다.

끝.

이번 포스팅은 App Store에 심사 요청하였으나 심사 거절을 당하였는데 거절의 원인은 아래와 같이 ITMS-91055였습니다. 따라서 원인부터 해결방법까지 한 번에 알아보도록 하겠습니다. 

목차

1. PrivacyInfo.xcprivacy의 정의

2. ITMS-91055: Invalid API reason declaration 원인

3. ITMS-91055: Invalid API reason declaration 해결 방법

4. 마무리

#1.PrivacyInfo.xcprivacy의 정의

에러의 원인에 대해 알아보기 전에 먼저 PrivacyInfo.xcprivacy에 대하여 알고 문제를 해결해야 하므로 PrivacyInfo.xcprivacy에 대해 알아보도록 하겠습니다.

Apple에서 공지한 게시글 '(23.12.7) App Store 앱 제출을 위한 개인정보 보호 관련 업데이트'와 '(24.2.29) App Store 앱 제출을 위한 개인정보 보호 관련 업데이트'를 살펴보면 아래와 같은 부분이 있습니다.

다시 말해 2024.05.01일 이후 XCFrameworks, Swift 패키지 또는 XCode 프로젝트로 배포되는 앱과 Third-Party SDK에는 PrivacyInfo.xcprivacy라는이름의 Privacy Manifest 파일이 포함되어야 합니다.

이 PrivacyInfo 파일은 마치 info.plist와 같은 Dictionary 구조의 소스코드를 Property List로 볼 수 있도록 만든 파일입니다. 다만 info.plist와 다른 점은 PrivacyInfo 내부에 정의된 값은 앱 또는 앱 내부 Third-Party SDK에 사용하고 있는 Privacy 정보들을 모두 정의해서 어떤 용도로 사용하고 있는지 나타내주는 역할을 합니다.

PrivacyInfo.xcprivacy =

앱 내부에서 개인정보를 사용하는 방식을 어떤 용도로 사용하는지 정의한 목록

PrivacyInfo.xcprivacy에 들어가는 목록에 들어가야 하는 정보는 아래의 총 4 가지입니다.

1. Privacy Tracking Enabled : 앱 및 SDK가 추적을 위해 데이터를 사용하는 지 여부

• 추적 사용 : YES
• 추적 미사용 : NO

2. Privacy Tracking Domains : 앱 및 SDK 추적을 위해 사용하는 Domain

• 추적에 사용되는 Domain을 입력하면 됩니다 ex) tracking.domain.example

3. Privacy Nutrition Label Types : 수집하는 정보가 추적과 관련되어 있는 경우 상세 설명 기재

• 보통 userId, name 등등이 추적에 포함된다면 추가하시면 될 것 같습니다.

4. Privacy Accessed API Types : 개인정보 Access 이유가 필요한 API로 지정된 앱 또는 Third-Party SDK가 Access 하는 API 유형을 설명하는 사전 배열

#2. ITMS-91055: Invalid API reason declaration 원인

PrivacyInfo.xcprivacy 파일은 앱 내부에서 개인정보를 사용하는 방식을 어떤 용도로 사용하는지 정의한 목록이라고 정의하였습니다. 정의된 내용을 토대로 에러의 원인에 접근하면 쉽게 알 수 있습니다.

에러가 발생한 아래의 에러메시지를 다시 살펴보겠습니다.

위의 PrivacyInfo.xcprivacy의 Privacy Accessed API Types의 DiskSpace, FileTimestamp 범주에서 API를 사용하기 위한 유효한 이유(Privacy Accessed API Reasons)가 기입이 되어 있지 않았습니다.  

ITMS-91055: Invalid API reason declaration - The PrivacyInfo.xcprivacy for the “Frameworks/libswiftDispatch.dylib” file contains “CA92.1:Acess Info from same app, per documentation” as the value for a NSPrivacyAccessedAPITypeReasons key instead of a valid reason code for using an API in the NSPrivacyAccessedAPICategoryDiskSpace category. Values for NSPrivacyAccessedAPITypeReasons keys in any privacy manifest must be valid reason codes for the corresponding API category. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api.

ITMS-91055: Invalid API reason declaration - The PrivacyInfo.xcprivacy for the “Frameworks/libswiftObjectiveC.dylib” file contains an empty string as the value for a NSPrivacyAccessedAPITypeReasons key instead of a valid reason code for using an API in the NSPrivacyAccessedAPICategoryFileTimestamp category. Values for NSPrivacyAccessedAPITypeReasons keys in any privacy manifest must be valid reason codes for the corresponding API category. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api.

#3. ITMS-91055: Invalid API reason declaration 해결 방법

원인은 Privacy Accessed API Reasons 이 기입이 되어 있지 않아서 발생하였으므로 제가 맡고 있는 앱의 성격에 맞게 아래와 항목을 정의하였습니다.

Privacy Accessed API Type

• Privacy Accessed API Type : DiskSpace
• Privacy Accessed API Reasons : CA92.1:Acess Info from same app, per documentation

• Privacy Accessed API Type : FileTimestamp 
• Privacy Accessed API Reasons : C617.1:Inside app or group container, per documentaion

참고로 앱의 Privacy.xcprivacy를 손 쉽게 만들어 주는 사이트를 소개합니다. 저도 여기에서 항목을 선택 후 Privacy.xcprivacy 파일을 다운로드 받아 프로젝트에 적용하였습니다.

https://wemakeapps.net/manifest-maker

#4. 마무리

아주 중요한 내용인데 글을 자세히 작성하면 글이 너무 길어져 최대한 쉽게 설명하려고 하였습니다. 이 PrivacyInfo의 핵심은 개인정보 보호인데 앱 내부에 있는 모든 개인정보 사용 API 즉, Firebase 및 Alamofire, Kingfisher 등 자주 사용하는 Third-Party SDK에도 사용하는 개인정보를 사용하는 이유를 모두 작성해야 한다는 것입니다. 앱 내부의 SDK의 흐름을 이해하고 최종 배포하는 것이 개발자 이므로 개발자가 이 흐름을 이해하고 Privacy.xcprivacy에 작성해야 한다는 것입니다.

긴 글 읽어 주셔서 감사합니다.

끝.

Reference : https://kemikim.medium.com/2024-05-01%EC%A0%81%EC%9A%A9-appstore-privacyinfo-xcprivacy-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0-d3d23a1f5fe7

Reference : https://h1guitar.tistory.com/323

Reference : https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api