자동차 회사에서 차를 만들 때 그 차만을 위한 고유의 비밀키/공개키 한 쌍을 만든다.
그리고 그 공개키에 매칭되는 인증서를 만든다.
(이 인증서 안에는 공개키가 들어가있음)
비밀키와 이 인증서를 차량 제조 할 때 설치한다.
이 인증서를 OEM Provisioning Certificate 라고 한다.
이 때 차량에 설치된 비밀키는 절대 외부로 유출되면 안된다.
인증서,공개키는 유출되도 상관없음. 비밀키만 유출 안되면 된다.
애초에 인증서랑 공개키는 외부에 공개하려고 만드는 것이다.
각각의 자동차 들은 각자 서로 다른 비밀키,공개키,인증서를 갖고 있을 것이다.
이러한 인증서를 지칭하는 고유한 번호가 있는데 이것을 PCID 라고 한다.
각각의 차량마다 서로 고유한 인증서를 갖고 있을 것이고, 인증서마다 고유한 PCID가 있으니까
차량 번호판 번호 같은 역할을 한다고 생각하면 되겠다.
PCID를 통해서 차량을 구분할 수 있게 된다.
제조사는 PCID를 차량구매자에게 알려준다.
차량구매자는 김철수, 해당 차량의 PCID는 1234라고 가정하자.
차량구매자는 본인 자동차의 PCID를 알고 있고, 전기차에게 전력을 공급하는 충전소 사업자(CPO; Charge Point Operato) 와 계약을 맺는다.
충전소 사업자의 내부 DB에 이 정보가 저장이 될 것이다.
전기차 A의 PCID는 1234 이고, 소유주는 김철수 이고 신용카드 번호는 1234-5678 . 뭐 이런식의 정보를 저장해 둘 것이다.
이제 김철수는 자신의 차를 몰고 충전소로 가서 충전을 하려고한다.
PnC 방식을 이용하여 자신을 인증하려고 한다.
이 때 , Contract Certificate 라는 인증서가 추가로 필요하게 되는데, 이 인증서는 앞에서 말했던 충전소 사업자(CPO)가
발행해서 EV에게 줘야한다.
차량 제조 당시에 설치되는 인증서가 아니기 때문에,
차를 사서 충전소에서 최초로 충전을 할 때는 자동차에 이 인증서는 없는 상태이다.
그래서 차량은 EVSE에게 자신의 OEM Provisioning Certificate를 알려주면서 Contract Certificate 설치를 요청한다.
(내가 갖고 있는 Contract Certificate가 없으니까 만들어서 나한테 줘!) 하는 요청이다.
그리고 지금 이 요청을 하는 것이 자신(김철수) 라는 것을 알리기 위해서 자신의 차량에 설치된 OEM Provisiong Certificate도 같이 보내준다.
EVSE는 이것을 받아서 이것을 CPO에게 전달한다.
CPO는 전달받은 OEM Provisioning Certifcate를 확인한다.
참고로 PCID는 OEM Provisioning Certifcate 를 구분해주는 번호라고 했다.
앞에서 차량 구매자가 PCID를 CPO에게 알려주는 절차가 있었기 때문에, CPO의 내부 DB에 해당 PCID가 저장이 돼있을 것이고, 그래서 전달받은 인증서를 보면 현재 충전소에 연결되서 인증서 발급을 요구하는 차량이 김철수의 차량이라는 것을 알 수 있다.
CPO는 김철수의 PCID 1234인 차량에 매칭되는 비밀키,공개키 한쌍을 새로 만든다.
그리고 Contract Certificate를 만든다.
이 Contract Certificate에는 방금 만든 공개키가 들어간다. 근데 특이한점은 방금 만든 비밀키도 인증서 안에 들어간다.
원래 인증서에는 공개키만 들어가고 비밀키는 발급자만 알고 있어야되는데 비밀키를 인증서에 같이 넣어버린다.
그러면 비밀키가 외부에 공개되버려서 문제가 생길 것이다.
그래서 비밀키를 그냥 넣는게 아니라 디피헬만 대칭키로 암호화해서 넣게된다.
추후 설명하겠지만 이 디피헬만 대칭키는 CPO 와 해당 PCID에 매칭되는 차량만 알 수 있다.
디피헬만 대칭키에 대한 설명은 뒤에서 다시 할 것이다.
무슨말이냐면 Contract Certificate가 외부에 아무리 공개되더라도
해당 인증서 안에 들어있는 비밀키는 디피헬만 대칭키로 암호화되어있으므로 , 암호를 해제하지 않으면 비밀키의 값을 알 수 없다. 그런데 이 때 암호화에 사용된 디피헬만 대칭키는 해당 자동차만 알 수 있으므로, 결론적으로
이 Contract Certificate를 받았을 때 안에 들어있는 비밀키 값을 알 수 있는 존재는 해당 자동차 뿐이라는 것이다.
eMAID가 다른 자동차들은 디피헬만 대칭키를 모르기 때문에 비밀키의 값을 얻을 수가 없다.
암튼 이렇게 발급된 contract certificate를 CPO가 EVSE에게 전달해주고,
EVSE는 이것을 다시 EV에게 전달해준다.
상황을 정리해보자.
특정한 자동차를 위한 공개키,비밀키,Contract Certificate가 생성되었고.
Contract Certificate 안에는 공개키, 디피헬만대칭키로 암호화 된 비밀키가 들어있다.
그리고 이것을 EVSE와 EV 모두 갖고 있다.
암호화에 사용된 디피헬만대칭키는 해당 EV만이 알 수 있으므로,
EVSE는 Contract Certificate가 있어도 공개키만 알 수 있고 비밀키는 알 수 없다.
반면 , EV의 경우 공개키 비밀키를 모두 알고 있는 상황이다.
이제 이것을 이용해서 인증을 어떻게 한다는걸까?
EVSE 는 Challenge라는 random number를 EV에게 퀴즈로 낸다.
EV는 Contract Certificate 안에 들어있는 비밀키를 이용해서 해당 Random Number의 서명을 생성해서 EVSE에게 답장을 보낸다.
EVSE는 비밀키는 모르지만 공개키는 알고 있다. 그래서 EV가 만들어준 서명을 공개키를 이용해서 검증한다.
여기서 서명,검증에 대해 간략히 설명하자면
EVSE가 만들어낸 랜덤 넘버를. EV가 비밀키로 암호화 한 결과물이 '서명' 이다.
EVSE는 이 '서명'을 공개키를 이용해서 복호화한다.
이때 복호화 된 결과물이 자신이 보낸 random number와 같다면 검증 성공이다.
검증에 성공했다는걸 무얼 의미하냐면, 서명을 만들어낸 EV가 Contract Certificate의 비밀키를 알고 있는 자동차라는게 증명된다.
그러므로 인증에 성공하게 된다.
이게 무슨 의미가 있는건지 이해가 되는가? 인증이 의미가 있으려면
다른 사람이 속이는 것을 방지 할 수 있어야 인증이 의미가 있다.
다음 상황을 생각해보자.
앞에서 예시로 들었던 김철수, 그리고 자신의 차량이 김철수의 차량인 것처럼 속이려고하는 김영희가 있다.
영희는 자신의 차가 김철수의 차 인것처럼 속여서 인증을 하려고 한다.
영희의 차가 EVSE에게 김철수 차량의 OEM Provisiong Certificate를 전달하면서 Contract Certificate를 만들어달라고 요청한다.
CPO는 Contract Certificate를 만들어서 EVSE에게 전달해줄 것이고, EVSE 는 이것을 영희에게 전달해줄 것이다.
이제 EVSE는 challenge 라는 Random Number를 만들어서 영희에게 보낼 것이다.
영희는 Contract Certificate 안에 들어있는 비밀키를 이용해서 Random Number를 암호화해서 '서명' 을 만들어서 EVSE에게 답장을 보내야한다. 그래야 인증에 성공하기 때문이다.
근데 여기서 문제가 생긴다.
영희는 Contract Certificat 안에 들어있는 디피헬만키로 암호화된 비밀키 값을 모른다.
그러므로 자신이 김철수인 것처럼 속일 수가 없다.
결국 pnC 인증과정에서 가장 핵심이 되는 부분은
Contract Certifiate 안에 들어있는 비밀키를 복호화 할 수 있는 디피헬만 키를 어떻게 김철수만 알 수 있냐는 것이다.
디피헬만키를 어떻게 만드는건지
편의상 상세한 내용은 다 생략하고 간략하게 설명해보겠다.
일단 G 라는 값이 있어야 하는데
G가 뭐냐면 그냥 한쌍의 숫자다
ex) (1,3)
(10,15)
뭐 이런 숫자 한쌍이 G다. 그렇다고 아무 숫자나 막 고르는건 아닌데 아무튼 숫자한쌍을 의미한다고만 알아두자.
정보를 주고받으려는 Bob과 Alice가 있다.
BoB과 Alice는 디피헬만 대칭키를 만들어서 남들은 모르고 자신들만 알 수 있게 공유하고 싶다.
그렇게하려면 일단 Bob이랑 Alice는 같은 G를 사용해야한다.
G 값은 외부에 공개 되도 상관없으니 어떻게든 서로 정보를 주고받아서 G 값을 통일한다.
예를 들어 G 값을 (1,3) 으로 정했다고 치자.
그리고 이제 BoB과 Alice는 각자 자신의 비밀키를 만든다. (남한테 공개 안하고 본인만 알 수 있게 고유한 값으로 정한다.)
예를 들어 BoB은 비밀키를 5, Alice는 비밀키를 9로 선정했다고 치자.
타원곡선 디피헬만에서는 비밀키값,G 를 사용해서 공개키를 만들 수 있다.
만드는 방법은 일단 생략하고 그렇구나 하고 넘어가자.
Bob은 Bob의 공개키를 만든다.
Alice는 Alice의 공개키를 만든다.
그리고 서로의 공개키를 서로에게 전달한다.
공개키는 외부에 감청되도 상관없으니까 안심하고 보낸다.
상황을 정리해보자.
현재 BoB은 자신의 비밀키, G 값, Alice의 공개키 값을 안다.
현재 Alice는 자신의 비밀키, G값, Bob의 공개키 값을 안다.
현재 외부에 노출 된 데이터는 G값, Bob의 공개키, Alice의 공개키이다.
자 이제
디피헬만 대칭키를 만들자.
Bob은 자신이 갖고 있는 비밀키값과 Alice의 공개키 값을 이용해서 어떤 값을 만들어내는데, 이 값이 디피헬만 대칭키다.
Alice도 자신이 갖고 있는 비밀키값과 Bob의 공개키 값을 이용해서 어떤 값을 만들어내는데 이 값이 디피헬만 대칭키다.
각자 만든 디피헬만 대칭키는 같은 값이다.
이를 통해, Alice와 BoB만 알 수 있는 대칭키가 서로에게 공유되었다.
실제로 대칭키 값을 통신을 통해서 주고 받지 않았음에도 불구하고, 둘만 아는 대칭키를 공유한 것이다.
이게 디피헬만의 원리다. 상세한건 다른 블로그 찾아보면 더 이해하기 쉬울 거다.
다시 PnC로 돌아오자.
CPO와 특정 자동차만 서로 알 수 있는 디피헬만 대칭키가 필요하다. 이것을 어떻게 만들어냈냐면!
자동차를 제조할 때 OEM Provisiong Certificate가 들어간다. 이 안에는 OEM Provisiong Certificate 공개키가 들어있다.
그리고 이 공개키 만들때 사용되는 G 값은 이미 알려져있다고 가정하자.
자동차가 CPO에게 Contract Certificate 발급 요청할 때, 자신의 OEM Provisiong Certificate를 보낸다.
CPO는 Contract Ceritifcatef를 만들기전에 공개키,비밀키를 생성한다고 했다.
이 때, 앞에서 말했던 그 G 값을 사용해서 공개키, 비밀키를 만드는 거다.
그리고 이렇게 만든 비밀키랑, 자동차로부터 전달받은 OEM Provisiong Certificate에 들어있는 공개키를 이용해서
디피헬만 대칭키를 만들어내는 것이다!!
이제 자동차 입장에서 생각해보자.
자동차는 CPO가 만든 Contract Certificate를 전달받을 것이고, 그 안에는 Contract Certificate 공개키가 들어있다.
자동차는 자신의 OEM Provisiong Certificate에 매칭되는 비밀키 값을 알고있다.(본인만 알고 있음)
이 비밀키랑, 전달받은 Contract Certificate 공개키를 이용해서 계산하면 디피헬만 대칭키가 나온다.
이것을 통해서.. 해당 자동차만 알 수 있는 디피헬만 대칭키가 만들어지는 것이다.!
'자동차 임베디드 SW > EVCC & 전기차 충전' 카테고리의 다른 글
| EVCC SLAC에 관하여 - 어떤 충전기에게 충전을 받을 것인가? (3) | 2022.09.24 |
|---|---|
| EVCC CP State와 Locking (1) | 2022.09.24 |
| EVCC 인증방법 EIM과 PnC (1) | 2022.09.24 |
| EVCC 충전타입 : 급속/완속충전 (1) | 2022.09.24 |
| EVCC 개요 (0) | 2022.09.24 |