다시 보는 iOS 개발을 위한, 인증 과정

iPhone OS가 발표 되고 나서, 이 인증과정은 그동안 참 말도 많고 탈도 많은 그런 과정을 거쳐왔다. Xcode 4가 나온 후에, 이 과정은 많이 간략화, 자동화 되어, 좀 더 편한 인증 절차를 밟게 되는 것으로 생각되었다. 그런데, 거의 1년 동안 iOS를 안만지다 만지게 되니, 1년전에 분명히 되는 것였는데, 안되어서, 다시 한번 처음부터 따라가보며 살펴 보았다. 이번엔 좀 정리가 더 잘되기를 기대해 보자.

자.. 인증 절차를 차, 포 떼고 꼭 필요한 요소만 보자.
인증엔 크게 두가지 과정이 필요하다.

1. Certificate을 iOS provisioning portal에서 발행하고, 각자의 컴퓨터에 다운 받아 등록한다.
2. Provisioning Profile을 역시  발행하고, 각자의 컴퓨터에 다운 받아 등록한다.

물론 이 둘 사이에 이런 저런 과정이 있다. 개발 타겟인 iOS 장비를 등록하고, 개발하는 어플리케이션의 ID를 등록하는 것이다. 그리고 요새 이상하게 설명이 빠지는 부분이 있는데 WWDR이란 인증서(Certificate)이 있다. 원래 이것을 제일 처음에 등록하는데, 참 기억하기 힘든 이름이다. WWDC도 아니고..  이것의 원래 줄이지 않은 명칭은 Apple Worldwide Developer Relations Certification Authority이다.

아무튼, 결국 저 1번과 2번을 등록하는 것인데, 뭐 이리 복잡하냐? 바로 그게 불만이다. 좀더 간단하게 할 수없을까? 초기 Xcode 4가 아니라 최근의 Xcode 4에서 (4.5에서 해 보았다) 분명히 간단해진 부분이 있다. 하지만 이 부분에도 문제가 하나 있는데, 이왕 이야기 꺼낸 거, 요번 기회에 다 해 보기로 하겠다. 그래봤자, 또 다음 Xcode 4에서 바뀌지 않을까 싶지만…

1번과 2번은 보안 시스템에서 이야기 하는, Private Key와 Public Key이다. 즉 Public Key Algorithm을 쓴다는 점이다. 아마 보안 시스템을 공부하지 않은 분들은, 여기서 또 헷갈릴 것이다. “아니, 분명 Private Key와 Public Key를 쓴다고 했으면, Private Key 알고리즘과 Public Key 알고리즘을 쓰는 것이지, 왜 Public Key를 쓴다고 말하냐?” 간단하게 말하자면 Public Key라고 하는 공개키 알고리즘은 Private Key가 있음을 가정한다. 즉 비밀 메시지를 주고 받아야 할 두 상대는 이미 Private Key를 각자가 가지고 있고, 이 두 Private Key는 서로 다르다. 즉 이 Private Key는 그것을 가지고 있는 이가 누구인지를 알려주는 역할을 한다. 반면에 두 사람 사이에 교환을 하는 Public Key는 “배달” 혹은 “전송”이 된다. 그러므로 이것은 누군가에게 날치기를 당할 수도 있고, 도청 당할 수도 있기 때문에, 항상 이런 저런 위험에 처해 있는 것이다. 그러므로 Public Key 알고리즘에서는 이러한 공개 키를 받은 각자의 비밀스러운 대화의 가담자들이 자신의 Private Key와 맞추게 되면, 두 키를 이용해서 계산을 함으로써 키가 맞는지, 또한 그것을 이용한 메시지가 변조 등을 당하지 않았는지를 안다. 즉 도청자는 public key만으로는 둘 사이의 비밀 메시지를 풀어 낼 수가 없다. 혹은 이런 저런 계산을 통해서 좁혀 나가서 결국 알아 낸다고 하더라도, 이미 시간이 지나버려, 두 대화 당사자들이 이미 키를 바꿔버렸을 가능성이 높아 버린다.

자. 이런 것이 공개 키 방식이다.
그럼 Apple의 개발자 인증 및 app signing 절차는, “너가 이 프로그램 개발자 맞느냐?”를 애플의 도구/서버가 물어보는 것이라고 한다면, 개발자는 자신의 컴퓨터에 가지고 있는 키를 이용해서, 애플의 도구/서버가 주는 퍼블릭 키와 매칭을 해서, 서로를 인증하는 것이다. 아마 어떤 간단한 메시지를 읽고, 그것을 다시 자신의 private key로 암호화를 하고, 보내면 서버 측에서 다시 그것을 까보고, 서버 본인이 보낸 메시지와 같은지 아닌지. 혹은 보낸 메시지에 대한 예상 답변을 했는지를 검사함으로써 인증을 하는 것일터이다.  그럼 결국 문제는 Private Key를 만들고 Public Key 를 보내고 매칭하는 것일 것이다. 저 위의 1번과 2번에서 그것이 함축적으로 나타난다.
이제 인증서나, Provision Profile이니 하는 도대체 뜻을 알 수없는 단어를 쉽게 Private Key와  Public Key로 바꾸면, 우리는 저 과정을 쉽게 이해할 수있게 되고, 뭘 왜 해야하는지 알게 되어, 굳이 애플의 문서를 때마다 읽어볼 필요가 없을 것이다.

자 그럼.. 무엇이 그 키들에 해당하는지 잘 살펴보자.
Certificate.. 인증서라는 뜻이다. 뭘 인증하겠다는 것일까? 내가 나임을 천명하니, 서버는 그것을 인증서해 발행하는 것이다. 예전의 iOS 인증절차 설명 문에서, KeyChain에서 Certificate를 만들는 것을 보자.

Requesting a certificate : 인증서를 발행 기관에 요청해서 받아 내기

즉 이 과정을 생활 언어로 표현하자면, “내가 나이니, 서버 자네가 이 사실을 증명하는 문서 하나 써 주게”이다. 즉 그러니 “인증서”를 발급하는 것이다.
즉 Certificate는 내가 나임을 증명하고, 네가 너임을 증명하는 private key가 된다.

자.. 그럼 이 후 과정에서, Provision Profile을 만들기 전에 중요한 과정이 App ID를 만드는 것이다. 이 App ID에 iCloud를 쓸 것인지, Game Center를 쓸 건인지 하는 자잘한 정보도 다 연결이 된다.

그리고 Provision Profile이 만들어지고, 이것을 내 개발 컴퓨터에 다운로드 받아 등록하게 된다.
즉 Provision Profile엔 App ID를 기반으로 만든 어떤 정보를 담고 있고, 그것이 다운로드 되어 내 컴퓨터에 등록을 하게 되면 key chain에 나의 private key와 관련지어진다. 즉 이것은 Public Key이다.
또한 이렇게 private key와 관련이 되어 질때, Xcode의 code signing 세팅시의 목록에도 나타나며, Xcode의 organizer에서도 Invalid Identity란 말이 안나온다.

여기에서 중요한 점이 있는데, private key와 public key, 다시 말하자면 Certificate과 Provision Profile을 연관 시키는 것이 무엇이냐는 것이다. (자, 엄밀하게 말하자면 Cetficiate은 private key 자체는 아닌 것으로 안다. 하지만 private key로 인해 발행된 인증서이므로, 문맥상 private key로 봐도 무방하다.)
오랜만에 iOS 샘플 프로젝트를 건드려 보면서, 이 부분이 안되었다.
Xcode 4 가 나온지 벌써 여러번 이 과정에 변화가 있었다 .그래서 혹시나 하는 마음에서 하나 하나 과정을 따라 갔다. 예전에도 안될땐 다시 처음부터 차근 차근이 하면 되었기 때문에. 단 요번 시도에서의 변수는, 집에 있는 컴퓨터에서 발행한(에서 만든 private key로 인해 발행된) certificate과 provision profile을 회사의 컴퓨터에서, 혹은 그 반대로 한다는 점이 달랐다. 이전에는 한 컴퓨터에서만 했다.

Apple의 “Launch Assistant”를 하면, 긴 문서를 읽지 않고도 쉽게 따라가면서 할 수가 있어서, 요번엔 그 방법을 써봤다. (예전엔 없었던 것이기도 해서)
이상하지? Provision Profiles라고 Xcode 4의 organizer 윈도우 내의 devices 탭 안에 있는 것에서, Invalid Identification 뭐.. 그런, 다시 말해 누가 발행했는지 모르는 profile provision이라고 나온다. Public Key 알고리즘 상, private key와 public key만 있으면 될텐데? 그러면 certificate과 provision profile만 있으면 되는거 아니야?
Launch Assistant 문서(과정)를 만든 사람은, 내가 보기에 이 부분을 이해 못하는 사람 같다. 혹은 알아도 잘못될 수있는 경우를 고려하고 문서를 작성한 것으로 보이지 않는다.
뭘까? 뭐가 잘못되었길래 “누가 했는지 모르는” 상태로 나올까?

우리는 여기서 p12 파일에 대해서 알아야 한다. p12 파일은 Personal Information Exchange File이라고 한다. 우리 말로 하면 “개인 정보 교환 파일”
뭐 일반적인 “개인 정보 교환용”을 말하는 것은 아니고, 인증 절차에서 그러한 것이 필요할 때 쓰는 파일이라는 것이다.  이 파일엔 뭐가 들어가 있을까?
제일 중요한 것이 즉 이 public key가 저 private key랑 연관된다고 알려주는 것이다. 이 파일은 이미 private key와 public key가 연관(association)된 컴퓨터에서,  key category이건 certification category에서건 export를 해 주면 생긴다.

Exporting P12, Personal Information Exchange file

 

그럼 다음과 같은 파일이 생긴다. 물론 파일 이름은 사용자가 정하기 나름이다.

Personal Information Exchange file

 

이제 이 파일을 다른 컴퓨터에 옮겨, ( 그 컴퓨터에서 certificate과 provision profile을 이용해서, 이미 제대로 이것들이 셋업된 컴퓨터의 환경을 그대로 재현하려 할 때 ) 거기서 더블클릭을 해주면, 바야흐로 certificate와 provision profile이 서로 연관지어지게 된다. 그럼 다음처럼 profile provision이 제대로 valid profile이라고 나온다. (개념상 그렇다는 말이다. 더 자세한 것은 뒤에서 설명해 보자)

Provision Profile

(어쩌면 여기서, 왜 Provision Profile이 위의 Library란 데에서도 있고, 밑에도 있냐는 생각을 하실 것이다. Library에 있는 것은 여러분의 컴퓨터에 있는 것이고, 각 장비 밑의 Profile Provision엔 그 장비에 설치된 Profile Provision을 의미한다. 즉 만약 장비 밑에 없고, Library 밑에만 있다면, 거기서 드래그 & 드롭해서 iOS장비에 설치할 수있다. 또한 이 provision 파일이 설치되어 있지 않은 컴퓨터에, 그 파일이 있는 iOS 장비를 연결하면 당연히 반대로 Library 밑에는 안나오고, 장비 밑에서만 나온다. 당연한 이야기지만… )

어차피 보는 김에 key chain에서 certificate과 key 부분에서도 봐 보자.

KeyChain의 key 카테고리에서 association된 private key와 certificate

KeyChain의 Certification에서 본 private key와의 연관 관계

즉 key에선 private key가 certificate과 연관된 모습을, certificate에선 certificate이 private key와 연관된 모습을 보여준다.
(여기서 어? private key인 certificate과 public key인 provision profile간에 연관된거 아니야? 라는 생각을 할 수가 있다. 나도 사실 헷갈리고, 읽기는 private key와 certificate이라고 읽고, 이해는 private key와 public key로 이해를 했었던게 사실이다. 그리고 그 public key를 profile provision이라고 생각하게 되었다. key chain에서. 물론 profile provision이 public key인 것은 맞다. 하지만 이 경우엔 마치 certificate이 public key인 것 마냥 private key와 연결되어 있다. 즉 이 key chain 항목이 뜻하는 바는, private key와 public key와의 연결 관계가 아니라, private key와 그에서 파생된 certificate과의 연관 관계를 보여준다. 즉 iOS developer란 private key가 iPhone Developer란 certificate과 연관 되어 있어, 해당  certificate의 identity를 확인할 수있게 해준다. 이것이 Xcode 4의 organizer에 가면 private key는 안보이고,  마치 certificate이 private key인양 (proxy라고 보면 되겠다) provision profile과 연결이 되는 것이다.

아.. 헷갈린다. 애플 문서의 헷갈림이, 이 인증과정이 쉽게 간략화가 안되는 것이 바로 이 세 파일 때문이다. 뭐가 public이고 뭐가 private인지 쉽게 눈에 보이지 않는다. 하지만 일단 알고 보면 보인다.

이 시점에서 앞의 p12에서 “뒤에서 알아보자”라고 했던 부분을 더 파보기로 하자.
분명  p12는 public key와 private key 를 연관시켜 주는 것이라고 말했다. 그런데 key chain엔 private key와 public key인 provision profile이 아니라 certificate과 연결이 되어 있다. 수상하다.
여기서 관념적인 설명을 버리고, 실제의 설명을 할 필요가 생긴다.
이 p12 파일엔 private key와 그것으로 인해 발행된 certificate을 포함하고 있다. 한번 key chain에서 private key와 certificate을 지우고, 지우기 전에 export한 p12 파일을 찾아서 더블 클릭해 보자. keys와 certificates 양쪽에 공히 이 둘이 연관지어져서 생길 것이다.
즉 key chain은 이 둘 사이의 관계만이 보여진다.
하지만 이 웹 사이트 및 다른 몇몇을 찾아보면 p12에 대해서 비슷한 설명을 다음과 같이 볼 수있다.

A P12 file contains a binary representation of a certificate, including both its public and private keys.

하지만, organizer에서만 볼 수있는 provision profile은 이 p12을 더블 클릭한다고 해서 생기지 않는다.
즉 key chain에는 certificate와 profile provision 사이의 연관이 아니라 certificate과 그것을 만드는데 사용한 identification인 private key만이 보이고, p12는 그것들을 포함한다. (자꾸 말을 반복하는 것은, 이 부분을 기억해야 하기 때문이다)

하지만 p12을 더블 클릭해야 비로소 organizer에서 valid profile이라고 나오는 것으로 보아서, 분명 이 p12에는 certificate과 provision profile간의 연관이 역시 기록되어 있는 것으로 보인다.

최신의 Xcode 4.4/4.5에선 예전과 달리 organizer에서 Teams 밑의 자기 이름을 클릭해서, 그 안에서 refresh를 하면, profile provision과 certificate이 자동으로 provision portal에서 다운로딩 되어 여러분의 컴퓨터에 설치된다. 무척 편해졌다. 즉 예전엔 포털에 가서 일일히 그 파일들을 다운로드 받고 설치해야했지만, 이젠 자동으로 된다. 문제는 이렇게 하면, 아까 언급했듯이 invalid identity 어쩌고 하는 식으로 나온다.
즉 private key(identity) – Certificate – Profile Provision의 삼각 편대에서, 뒤 두개가 다운로드되고 서로 연관되어 지지만 private key가 제대로 처리되질 않아 invalid identity가 나온 것이다.
반면에 key chain에서 export 한 p12는 앞의 두개, 즉 private key와 certificate는 설치할 수있는 정보를 갖고 있지만, profile provision은 정보를 가지고 있지 않다.
그러므로, Xcode 4의 이 인증과정이 예전에 비해 좋아졌다고는 하지만, 여전히 Xcode 4에만 의존할 수없다는 것이다.

이상으로 이 인증과정의 뒤에서 무슨 일이 벌어지는지는 설명을 했으니, 요점만 간단히 어떻게 하면 한 컴퓨터에서 셋업한 인증 환경을 다른 컴퓨터로 옮길 수있는가를 보면 딱 두개를 해 주면 된다.

1. Organizer의 팀 멤버 이름이나, provision profile에서 refresh를 눌러 certificate과 profile을 다운 받는다. (포털에 직접가서 다운 받아도 된다)
2. 원래의 컴퓨터에서 key chain을 열어 certificate을 찾거나 그와 연결된 키를 찾아서 p12을 export하고, 인증 환경을 똑같이 만들 컴퓨터에서 (즉 1의 과정을 한 컴퓨터) 설치를 해준다.

쉽지? 쉽잖아.

아! WWDR 그건 protal에 가서 다운 받아 설치해보자. 언젠가부터 이 파일에 대한 언급이 은근 슬쩍 스리 슬쩍 빠졌다. 애플 문서에서.. 뭐 찾아보면 어디에 숨어있겠지. 아마 이 파일은 여러분이 애플에 개발자로 등록되어 있다는 것을 입증하는 파일로 보인다. 예전에, 먼저 이 파일을 만들고 그 다음에 그것을 다운 받은 후에 certificate 파일을 만들기 위해 key chain에서 request하고 했으니, 이것은 일종의 seed file처럼 쓰일 것이다. 그러니 그냥 설치하자.

끝! 휴…