FDO: FIDO 디바이스 온보드 프로토콜 안내
<FDO 소개>
FIDO Device Onboard 에 대해 소개하고자 합니다.
IoT 즉 사물 인터넷하면 4차산업혁명 얘기도 많이하고 실제 IoT가 우리 실생활에서 많이 사용되고 있어 아직도 IoT에 대해서 핑크빛인 사람들도 많고, IoT가 뭐냐 이렇게 얘기하시는 분들도 많지만 실제로 어떤 트랜드라기 보다는 어떤 사물이 인터넷에 연결되어 있으면 다 무조건 IoT Internet of Things 라고 볼 수 있음
다시 말해서 어떤 기기가 있는데 그게 혼자서 동작을 한다면 IoT가 아니고 그게 네트웍이랑 붙어서 어떤일을 한다면 그것은 IoT라고 할 수 있겠습니다. 예를 들면 과거에 보일러로 단순 온도 조절하는 것들은 IoT가 아니지만 그것이 와이파이랑 붙어서 집 밖에서 제어를 하거나 이럴때 인터넷에 붙어 있으면 그것은 IoT기기가 됨
<FDO의 탄생 배경>
그런데 가장 문제가 이 기기가 만들어진 곳에서 부터 인터넷에 붙을때까지 그 구간이 생산자나 클라우드서비스에 따라서 많이 달랐기 때문에 거기에 대한 표준화 작업이 좀 필요하다고 생각해서 파이도에서 그것을 시도하게 됨
[FDO 스펙]
IoT 디바이스는 결국 Cloud 와 접속해야 서비스를 할 수 있고 디바이스의 순정성과 무결성을 어떻게 처리할 수 있는지 고민을 해야 하고 그래서 익명의 installer 에 대해서도 관계없이 Trusted installer와 같이 온보딩 할 수 있는 기술에 관심을 가지고 있고 기기 자체의 보안이라기 보다는 클라우드나 네트웍에 붙을 때 어떤게 활용될 수 있는지에 대한 기술임
그래서 인텔의 SDO(Secure Device Onboarding)을 사용해서 인텔의 자체기술중에서 표준 암호화 함수만 사용하고 기존 기술을 가능하면 재사용하여 사용도 제고하고 Device 자체의 문제는 TPM(Trusted Platform Module)로 해결함
이 기술은 좋지만 인텔이 원하는 방향으로 갔고 이 기술은 시사하는 바도 굉장히 크고 쓸모가 많은 표준이라고 생각함
[FDO 장점]
Fast, Scalable & Secure 하고 Device 프로비져닝 과 온보딩과 엑티베이션 기능이 있고 장점으로는 제로 터치가 가능하고
* 제로 터치란 중간에 가서 configuration 하지 않고 컴퓨터 연결해서 이런 것 하지 않고 네트웍에 꽂으면 온보딩 할 수 있고 빠르게 안전하게 만들수 있음
또 다른 특징은 Late-binding이고 이것은 디바이스 자체가 클라우드에 붙을 때 끝에 가서 붙는다는 얘기임
그래서 과거에는 제로터치를 하더라도 FDO가 없었다면 디바이스를 만들어서 유통 채널을 거친 다음에 클라우드에 붙을 때 특정 클라우드에 붙도록 되어 있었고 이제 FDO 를 사용해서 제로터치를 한 것은 똑같은 제품을 만들어서 유통 채널을 거친 후 맨 끝에 가서 바인딩(Late-Binding) 을 통해서 맨 마지막에 클라우드에 붙을 때만 클라우드의 어떤 특징에 따라 다르게끔 하고 그 과정에 대한 인프라스트럭쳐가 있어야 되는데 이것을 FDO 에서 다룸
그래서 late-binding을 위해서는 manufacturer의 크리텐셜이 살아있어서 끝까지 가야하고 그다음에 웨어하우스 같은 경우는 final destination이 뭔지 모르는 상태에서 디바이스를 웨어하우싱해야 하는데 어떤 유통과정을 겪던지 간에 그 유통에 대한 이력들이 살아있거나 아니면 그것이 관리되어야 함 그리고 그런 것들이 프로비젼닝할 때 flexible 하게 제공 되고 네트웍도 아까 클라우드란 말을 사용했지만 closed network 이 나 인트라넷 심지어는 폐쇄망이 되도 관계는 없고 아무튼 네트웍이랑 붙어서 뭔가를 서비스할 때 필요한 것들이 late-binding으로 나타나야 됨
<FDO 프로토콜>
FDO는 Ownership Voucher 란 것이 있어서 이게 바로 이력서 라고 생각하시면 되는데 이것이 크리덴셜을 가지고 있고 처음에 manufactorer가 크리덴셜이랑 디바이스에 대한 정보를 넣고 유통과정을 막 거치다가 보면 맨 끝에 가면 이 제품을 사는 오너가 생기는데 유통과정에서 이력들이 쭉 쌓이다가 끝에 가서 이 Owner는 결국에는 앞쪽에 있는 디바이스 크리덴셜하고 연결이 되야 하는데 그것을 연결해 주는 프로토콜을 FDO 프로토콜이라고 함
<FDO로 프로비전닝하는 과정>
어떤 디바이스의 넘버 시리얼키를 가지고 있다가 manufactor가 Ownership Voucher를 뿌리는데 실제 디바이스는 유통과정을 거쳐서 이동하다가 이 바우쳐들은 유통과정에서 쭉 살아남다가 그게 끝에 가면 타켓 클라우드 (Owner가 지정한 클라우드)나 응용시스템에 붙게 되고 FDO에서 얘기하는 랑데뷰 서비스랑 타켓 클라우드가 Ownership 바우쳐를 받을면 랑데뷰서비스랑 같이 연결을 해서 랑데뷰 서비스에게 이 디바이스에 대한 정보를 제공하게 되고 타켓 서비스는 그 다음에 디바이스를 기다리고 랑데뷰 서비스도 기다린다. 그럼 디바이스가 유통과정을 거쳐서 집으로 가서 언박싱을 하고 딱 열면 제일먼저 붙는 곳이 타켓이 아니고 랑데뷰 서비스에 먼저 붙는다
이때 랑데뷰 서비스가 여러가지가 있다면 이 디바이스가 지정한 랑데뷰 서비스에 대해서만 붙게 됨.
그런 다음에 랑데뷰 서비스가 아 너구나 너 이제 언박싱했네 이렇게 되면 그 다음에 너는 그러면 요 클라우드를 연결해 그리고 그 클라우드에 어떤 정보를 주고 그럼 디바이스는 클라우드에 붙게 되고 그럼 클라우드가 아 너구나 내가 지금까지 널 기다렸으니깐 late-binding하고 붙은 다음에 여러가지 왔다갔다하면서 여러가지 일을 하고 그 다음에 power on 하고 제대로 사용하게 되는 과정을 거치고 이게 바로 FDO를 활용한 프로비젼닝 과정임
<FDO 프로토콜별 설명>
그리고 FDO에서는 Transfer Owner 라는 프로토콜을 사용하는 3가지 TO0 , TO1, TO2 가 있고, 서버랑 붙을 때 이런 프로토콜들은 http, https 주로 https 를 사용해서 굉장히 안전하게 왔다갔다 하게 됨
[프로토콜별 설명을 하기전에 공인인증서 사용 방법]
제일 중요한 것은 생산자가 여기서 키페어를 생산해야 한다. 이 안에서 퍼블릭키 , 프라이빗키를 생성해가지고 그런것들은 아까 나온 TPM이나 Security 엔진 같은 곳에서 하고 있고, 좀 더 중요한 디바이스인 경우 예를 들어 이게 자동차 라던가 아니면 굉장히 중요한 것들은 생산자가 자기자신의 키페어를 생산하는 것은 조금 문제가 있어보여서 이런 것들은 보통 공인인증서를 사용하는데 공인인증서란 것이 인증기관에서 private key 와 publice key의 Randomness를 굉장히 안전하게 만들어주는 것이고 그래서 이것을 내려보내서 그 안에다 manufactoring info를 집어넣고 디바이스 내부에 이 크리덴셜 즉 public key , private key 같은 것을 안전하게 저장함
이 때 디바이스 생산자 정보(언제만들었는지 , 누가 만들었는지 등 )는 설정이 되어 있어야 하고 그래서 이 프로비젼닝 서비스같은 경우에는 보안을 강화해서 공인인증서를 사용함.
[DI 프로토콜]
IoT 디바이스 안에 여러가지 컴포넌트 들이 있는데 그런것들에 대해서는 어떻게 할 것이냐? 이것을 그냥 initialize 하는것을 DI (Device Initialization) 프로토콜의 단계에서 하고 이것은 Device Initialization 이라기 보다는 FDO 프로토콜의 late-binding에서 필요한 어떤 크리덴셜을 만드는 거라고 생각하면 됨
그래서 DI 프로토콜을 시작하기 전에 어떤디바이스간에 오퍼레이션 펌웨어가 있어야 하고 커뮤니케이션 프로토콜이 있어야 하고 그다음에 ROE (Restricted Operation Environment)-즉 제한된 운영 환경을 만족시키는 보안 모듈같은 것이 있어야 합니다. 이런 것들이 제대로 갖쳐져 있고 제대로 되어 있어야지 DI 프로토콜을 사용하기 용이 함
[TO0]
이렇게 해서 디바이스가 준비되면 디바이스는 쭉 유통을 흘러가고 Ownership 바우쳐가 나왔을 때 이쪽 Transfer Ownership 단계가 0 이라고 해서 TO0라고 하고 이것은 디바이스랑 관계가 없고 클라우드가 디바이스에 대한 정보를 받아서 랑데뷰 서버에 정보를 주는 단계를 TO0 라고 함
클라우드에는 바우쳐 정보도 , 공개키에 대한 비밀키 ,또 공개키 정보를 다 가지고 있고, 여기에 자기 IP 주소를 가지고 있어야 되고 , 랑데뷰 서비스는 적어도 ownership 바우쳐에 대한 생산자 공개키 정도는 가지고 있어야 되는데
서로가 함께 아 이 디바이스가 오겠구나 하고 OOS쪽에 알려주고 랑데뷰 서버는 나중에 이런 GUID를 가진 디바이스가 붙으면 오너에 대한 정보를 내가 전해줄게 하고 기다리고 있는 상황
[TO1]
디바이스를 Owner가 받아서 인터넷에 딱 꽂으면 랑대뷰 서버에 접속하고 접속이 되면 너 그렇지 않아도 기다리고 있었어 너 GUID가 이거지 서로가 verify를 하고 verify 과정을 통해서 id를 받고 그다음에 너는 이런 서버에 접속을 하면 돼 이렇게 해서 그 정보를 줍니다. 그래서 KT, SK, AWS 등 다양한 클라우드 서버에 붙을 수 있음
예를 들면 만약에 어떤 냉장고나 세탁기가 있다면 이 세탁기가 kt서버를 사용한 서비스가 있을 거고 아니면 sk서버를 사용한 서비스가 있을거고 해서 여러가지 디바이스가 여러가지 다른 서비스에 멀티풀로 붙을 수 있는 것도 가능하고
중고로 팔았을 때 그 오너쉽 바우쳐를 새로 만들어서 붙여 그 후 랑데뷰서비스랑 다시 붙여서 다른 오너가 사용할 수 있는 재사용도 가능함
[TO2]
랑데뷰서비스를 거쳐서 클라우드가 디바이스를 만나면 서로가 인증을 하고 서로 만났으니깐 새롭게 키를 만들자 해서 키 교환을 하고 디바이스에 있는 사용자 정보를 인식하고 Attestation 와 인증서를 제외하고는 모든 크리덴셜을 대체함 그 후 필요하면 펌웨어 업데이틀 한다든, 명령어를 실행한다든지, 어려가지 제반 명령어 수행 등 응용에 필요한 오퍼레이션을 하고
이렇게 해서 디바이스가 준비가 되고 그럼 서비스가 시작됨
~~~~ 좀 더 깊이 들어가면
생산자가 디바이스를 유통에 넘길때 이 Ownership Voucher에 publice key랑 이 디바이스의 id와 인포메이션을 해쉬한 private key를 집어넣고 유통에서는 자기 public key 가 있고 이쪽 생산자의 publice key 도 가지고 있고, 또 유통이 가지고 있는 인포메이션등을 사인을 한 후 여기에 자기 public key를 붙이고 또 그 다음 유통에서도 반복하다가 마지막에 오너까지 가게되는데 이 과정은 TO2 이후에 일어나는 일.
이 과정에서 넘겨받은 퍼블릭키를 자기가 가지고 있던 해쉬넘버랑 비교를 해서 같으면 verify 된거다고 간주함
컨셉은 넘어 받은 이 publice key를 활용해서 안쪽에 ROE안에 들어있던 디바이스랑 verify 과정을 거치고 그 다음에 1번이 verify 되면 그 후 2번도 , 3번도 verify를 거치고 그 과정이 다 끝나게 되면 verify가 완료되었으니깐 너는 이런 생산자를 시작해서 이런 유통과정을 거쳐서 나한테 왔네라는 사실을 알수 있고 맨마지막에 자기가 만든 private key와 publice key를 가지고 verify하는 그런 과정을 겪음(원리는 이렇고 표준문서에는 좀 더 복잡하게 설명되어 있음)
< FDO 를 적용하기 위한 보안 기술>
Ownership Voucher를 설치를 해서 이력을 하나 하나씩 거치고 그 디바이스랑 오너와 서로 verify하는 과정에
ROE(Restricted Operating Environment)라는 것이 있고 이것은 응용프로그램이나 cpu가 들어갈 수 없는 어떤 영역 제한된 영역인데 크리덴셜을 안전하게 숨기고 저장을 하고 여러가지 크립토에 관련된 것을 execution 하고 관련 펑션들을 돌리고 이런 것들을 하게 되는데 것으로 이것은 sw나 hw e모두 가능함
sw라도 인텔과 같은 cpu면 그 안에 tpm 이 들어있을 수도 안들어있을 수도 있으니깐 방법은 secure os안에 어떤 키를 숨겨서 할 수 있는 방법도 있고, hw를 사용해서 할 수 있고 아니면 tpm이란 모듈을 심어서 할 수도 있고 다행함.
최근에는 tpm이 embedded 된 칩들도 있음
또 거기에 대한 각각 표준들이 있어서 그런것들을 사용해서 안전하게 숨기는 것에 대해 얘기하고 있고 어떤 디바이스를, 어떤 칩를 선택하고, 어떤 environment를 선택할지는 생산자와 오너와 협의해서 어떤 보안에 대한 리즈가 필요한지 확인후 알맞은 ROE를 제공해야 한다. 이것이 생산자에게 제일 중요한 것임
<Owner Voucher 관리>
오너 바우쳐(Owner Voucher)는 아주 복잡한데 예를 들어 세탁기를 예를 들면 컴포넌트도 많고 cpu도 많고 그외 여러가지 돌아가는 것들이 굉장히 많은데 Device initialization은 어디서 해야 하는지 ?
이것을 앞에서 해야 하는것이지, 다 끝나고 해야하는것인지, 그리고 메인 tpm은 어디에 들어가야 하는건지, 이게 세탁기 처럼 간단한 것은 관계가 없는데 자동차같이 복잡한 것은 function이 나눠져 있어서 이런것을 어떻게 하느냐가 가장 중요한 것 중에 하나임.
그런것이 아직 define이 깨끗하게 안되어있어서 그것은 생산자가 사용자와 클라우드 서비스업체랑 애기를 해서 만들어야 되는데 이때 너무 어렵게 만들지 말고 flexible 하게 해 놓는게 좋음
또 오너바우쳐까지 나오면 각각 유통기관에 따라 오너바우쳐 가 쭉 따라가면서 가는데 각각 유통에서 오너바우쳐를 가지고 가는데 이 오너 바우쳐가 디바이스랑 같이 즉 세탁기가 가는 곳마다 따라가는 것이 아닐 수도 있어서 때로는 이런 일련의 과정을 건너뛰고 바로 오너에 붙을 수도 있어서 이런 경우 사용자의 입장에서는 생산자가 누군지는 알지만 중간에 어떤 이력을 거쳤는지 잘 모르는 경우가 있는 등 오너바우쳐의 관리나 이력같은 것들을 관리할 지가 가장 큰 이슈중에 하나임
설치자가 오너바우쳐를 어떻게 할 것인가란 문제가 있는데 이것은 좀 디테일한 문제이기에 각각 응용에 따라서 다르게 관리를 한다고 생각됨
<결론>
FDO 기술은 IoT가 발달됨에 따랄 디바이스와 클라우드가 다양향 형태로 나타니게 됨에 따라 이에 대한 이력을 어떻게 안전하게 관리하고 보안을 강화할 수 있는지에 대한 연구를 하는 과정에서 나온 것으로
<현 상황>
국내에서는 특정기긱가 특정 클라우드에만 접속되지만, 미국등 해외에서는 기기가 다양한 클라우드를 사용할 수 있는 옵션이 있음
즉 디바이스 사용자가 클라우드 서비스를 선택할 수 있는 장점이 있고
또 Iot 디바이스가 공장에서 출하하여 , 사용자(혹은 설치자)에 의해 클라우드에 연결될때까지 보안에 대한 표준이 없어 그 표준을 만들 필요가 있음
<FDO로 해결될 일들>
1) 디바이스 생산부터 Ownership에 대한 이력관리가 가능
2) 디바이스의 새로운 사용자에 의해서 재사용도 같은 프로토콜로 관리가 가능하고 디바이스의 설치가 Truested installer 인지 아닌지에 무관하게 On-boarding 이 가능하고
3) Owner Voucher 관리의 경우 블록체인 기술과 접목하여 관리가 가능할 것 같고 원산지 표시 및 이력관리 등에 광범위하게 적용될 것으로 판단됨
댓글 없음:
댓글 쓰기