본문으로 건너뛰기

인증

1. 인증(Authentication)의 의미와 역활​

IO시그널에서의 인증이란 시그널서버에 접속하는 클라이언트의 디바이스 ID 와 디바이스 암호키를 검증하는 과정입니다. 인증을 통과한 장치는 약속된 CID(장치를 위한 메일주소같은 통신ID)를 사용하여 소통이 가능해지고, 익명 접속 클라이언트와 차별화 된 서비스를 제공 할 수 있습니다.

인증이 중요한 가장 큰 이유는, 인증이 완료된 이후 서버와 클라이언트는 암호 통신을 한다는 점입니다. 리모트 시그널은 보호(Boho)로 불리는 경량 암호 모듈을 내장하여 안전한 인증과 암호통신 기능이 제공됩니다. 더불어 E2EE 같은 고급 기능까지 제공하여 중계 서버 조차도 해독이 불가능한 P2P 시그널 전송이 가능합니다.

2. 인증과 암호통신을 위한 사전작업​

2-1. 인증용 필수 정보​

서버와 클라이언트가 서로를 인증하기 위해서는 사전에 공유된 장치ID와 암호키가 필요합니다. 또한 효과적인 시그널링을 위한 통신 ID 도 포함합니다. 이밖에 부수적인 정보는 서버측 데이타베이스에 추가될 수 있습니다. 위 3가지 정보는 인증과 암호화 시그널링에 필수정보입니다.

  • 디바이스 ID( Device Id)
  • 디바이스 암호키( Device Key)
  • 통신 ID( Communication Id : CID)

2-2. 인증 정보의 생성과 장치 이식​

IO시그널은 자원소모가 큰 공개키 교환(PKI)기능을 제공하지 않으므로, 인증과 암호통신이 가능하려면 서버와 클라이언트가 사전에 암호키를 공유해야합니다. 아두이노 같은 임베디드 디바이스의 경우 소스코드에 직접 인증정보를 이식하는 방법과, 서버와 안전한 통신이 가능한 웹브라우저나 앱을 경유하여 키 생성 및 전송된 정보를 이식하는 등의 다양한 방법이 가능합니다. 웹 브라우저 같은 디바이스는 웹 토큰같은 기술을 활용할 수도 있습니다.

3. 서버측 인증 정보 연동​

서버는 별도로 인증 옵션을 지정하지 않을 경우 무 인증으로 운영됩니다. 인증 기능을 사용하려면 이를 위한 기반모듈을 별도로 개발하여 연동해줘야합니다. 데이타베이스 연동 외에도 인증 기술의 구현과 검증을 위한 암호화 기술의 이해가 필요합니다. 이때문에 직접 인증서비스를 개발운영하는 것은 대부분의 개발자에게도 난해할 수 있는 부분입니다.

이때문에 참고할 수 있는 두가지 유형의 인증 구현방식을 iosignal-cli 프로그램과 IO시그널(IOSignal)라이브러리 소스코드에 포함하였습니다.

  • 서버 구동시 d 옵션으로 인증파일을 선택해주는 간단한 인증방식과
  • Redis 같은 전문 데이타베이스 연동 예제를 함께 포함하고 있습니다.

4-1. 인증정보를 기록한 JSON 파일을 사용하는 인증방식​

  • 소규모 또는 개인 서버 용도로 충분합니다.
  • JSON 형식의 일반 텍스트 문서 파일 하나를 사용합니다.
  • 문서 편집기로 간단히 인증정보를 수정할 수 있도록 암호키를 암호화 되지 않은 평문으로 저장합니다.
  • 장치 하나당 인증 필수정보로 3가지 정보만 사용합니다. deviceId, deviceKey, deviceCId
  • 리모콘 프로그램 소스코드 root 폴더에 예제 파일이 제공됩니다.
  • auth_file.json 파일을 찾아서 수정하여 사용하시면 됩니다.
  • 파일명은 바꾸셔도 됩니다.
  • 아래와 같이 -d 옵션으로 인증파일을 선택하여 구동하면 됩니다.
$ io-server -d auth_file.json

4-2. 인증파일의 구조와 제한​

  • 장치ID(device id)는 영문 8문자로 제한됩니다.
  • 장치키(device key)의 길이는 SHA256 해쉬연산으로 32바이트 값으로 변환되어 사용되므로 길이 제한은 없습니다. 다만 아두이노 클라이언트의 경우 메모리 크기가 문제 될 경우 적당한 크기로 제한해주시기 바랍니다.
  • 통신 ID(CID)의 길이는 최대 20문자로 제한합니다. (이 길이 제한은 향후 변경될 수 있습니다.)
  • 중요. JSON 포맷은 주석문(Comment)을 포함할 수 없습니다. 문자열은 “”쌍따옴표로 묶어줍니다.
  • 실제 예는 아래와 같습니다.
[
  ["id","key","cid",1],
  ["did2","did2key","did2-cid",1],
  ["uno3","uno3-key","uno3-cid",1]
]

5-1. Redis 및 기타 데이타베이스 연동시​

  • 권장되는 방식입니다.
  • 아래의 공개소스 저장소에서 실제로 Redis 와 연동되는 인증 절차 구현코드를 참고하실 수 있습니다.
    • AuthRedis.js , .. ( remocon/src )
    • AuthCore.js ( remote-siganl/src/auth )
  • Redis 서버가 이미 운영되고, 인증 자료가 이미 주입되어야 작동 가능합니다.
  • Redis 에 샘플 인증 데이타를 주입하는 소스코드 예제도 포함되어 있습니다.

5-2. Redis 인증 서버 구동​

Redis 서버와의 연동 준비가 완료 된 이후 아래의 명령을 통해 인증서버 구동이 가능합니다.

$ io-server-redis

6. 클라이언트의 인증​

  1. 인증 기능이 작동중인 서버를 실행합니다.
  2. 서버에 접속합니다.

아두이노 및 웹브라우저 클라이언트 프로그래밍시 인증 방법은 별도 문서로 소개 드리겠습니다.

아래는 리모콘CLI 프로그램으로 서버에 연결후, 로그인 명령으로 인증을 시도하는 예제입니다. 초기 접속시엔 익명접속 상태입니다. 이후 로그인이 성공하면 익명 CID가 사전에 등록된 CID(아래에선 uno3-cid )로 변경됩니다. 이때부터는 해당 CID로 다른 디바이스와 1:1 통신이 가능해집니다.

$remoteready:  cid: ?YXDr   // 초기 접속시 미인증 상태이므로 임시 CID를 발급받았습니다.

> .login uno3 uno3-key   // 로그인 명령으로  장치ID와 장치Key를 입력합니다.

try manual login:  uno3
> >> QUOTA_LEVEL :  1
current quota: {"signalSize":255,"publishCounter":10,"trafficRate":100000}

ready:  cid: uno3-cid    // 인증이 성공한 경우,  인증 데이타베이스에 등록된 CID를 새로 부여 받습니다.

# now device have (pre-registered) CID.

7. 인증과 미인증의 차이​

이미 간단히 설명했듯이 미 인증 클라이언트와 인증 클라이언트는 차이가 있습니다.

7-1. 미인증 클라이언트​

  • 전송 가능한 시그널의 크기가 매우 제한됩니다.
  • 멀티캐스트 시그널의 수신 가능한 구독자 수가 적습니다.
  • 접속시 마다 CID가 바뀝니다. 1:1 소통이 더 어려워 집니다.
  • IO시그널 전용의 암호 통신이 불가능합니다.
  • 단, 웹브라우저의 경우 서버와의 통신은 WSS/TLS로 연결될 경우 보호됩니다.

7-2. 인증된 클라이언트​

  • 전송 가능한 시그널의 크기가 미인증 경우보다 큽니다.
  • 전송 트래픽 허용량은 인증 레벨 별로 차등화 됩니다.
    • 시그널 크기
    • 멀티캐스트 시그널의 수신 가능한 구독자 수
  • 고정된 전용 CID가 사용되어. 1:1 소통이 용이해집니다.
  • TLS 미지원 통신 라인에서도 안전한 IO시그널 암호 통신이 가능합니다.
  • 웹브라우저의 경우 서버와의 통신이 WSS/TLS로 연결된 경우 자체 암호화 기능은 기본적으로 사용되지 않습니다. 하지만 필요시 명시적으로 사용 여부를 선택 할 수 있습니다.