LoRaWAN 1.1 보안 부분 분석(LoRa Spec 6장 일부분 번역)

과거 메모 : 2018년 ~ 2019년 초 자료인듯

 

LoRaWAN 1.1 spec Part 6 번역

6. End-Device Activation

디바이스가 LoRa 네트웤에 붙기 위해서는 활성화 절차를 밟아야 한다.

디바이스의 활성화 절차는 두가지가 있다. OTAA(Over-The-air-Activation), ABP(Activation By Personalization)이다[1].

6.1 Data Stored in the End-device

6.1.1 Before Activation

6.1.1.1 JoinEUI

JoinEUI는 IEEE EUI64 주소체계에 맞는 글로벌한 어플리케이션 Identifier이다. 해당 Join 서버는 EUI를 유일하게 식별한다(Join 서버는 Join 과정, 세션키 운반 같은 것을 도와줌[2]).

OTAA디바이스의 경우, Join 과정을 하기 전에 JoinEUI는 디바이스에 반드시 저장이되어야 한다. ABP 모드의 경우 JoinEUI 필요 없다.

6.1.1.2 DevEUI

DevEUI는 IEEE EUI64 주소체계에 맞는 글로벌한 디바이스 Identifier이다.

DevEUI는 NS에서 권고되는 유니크 디바이스 Ientifier이다. 활성화 절차를 하거나 네트웤을 통해 로밍을 할 때 식별한다.

OTAA 디바이스의 경우, Join 과정이 되기전에 DevEUI가 디바이스에 반드시 저장되어야 한다. ABP는 DevEUI가 저장될 필요가 없다.

6.1.1.3 Device root keys( AppKey & NwkKey )

NwkKey, AppKey는 AES-128는 디바이스에 할당된 rootKey이다. 디바이스가 OTAA를 통해 네트웤에 Join을 할 때 마다, NwkKey는 FNwkSIntKey, SNwkSIntKey, NwkSEncKey 세션키 3개를 유도한다. AppKey는 AppSKey 세션키 1개를 유도한다.

Secure provisioning, storage, and usage of root keys NwkKey and AppKey on the end- device and the backend are intrinsic to the overall security of the solution. These are left to implementation and out of scope of this document. However, elements of this solution may include SE (Secure Elements) and HSM (Hardware Security Modules). => 키 관리는 본문(로라스팩)에서 안다룸

LoRaWAN 1.0과의 호환성이 필요할 때는 NwkKey만 사용한다(1.0은 AppKey라는 한 개의 키만 사용하는데 그것을 NwkKey로 대체해줌).

The end-device in this case MUST

-      Use the NwkKey to derive both the AppSKey and the FNwkSIntKey session keys as in LoRaWAN1.0 specification. è FNwkSIntKey가 1.0의 NwkSKey가 된다는 얘기

-      Set the SNwkSIntKey & NwkSEncKey equal to FNwkSIntKey, the same network session key is effectively used for both uplink and downlink MIC calculation and encryption of MAC payloads according to the LoRaWAN1.0 specification. è NwkKey에서 유도한 3개의 세션키를 똑같이 만들고 uplink, downlink 때 사용해라~

NwkKey, AppKey는 OTAA 방식에서는 반드시 저장되지만, ABP 방식은 아니다.

NwkKey와 AppKey는 재사용되지 않게 안전하게 보관해야 한다.

6.1.1.4 JSIntKey and JSEncKey derivation

OTA 디바이스는 NwkKey로 유도되는 키가 아래와 같이 있다.

-      JSIntKey: MIC Rejoin-Request type 1 메시지와 Join-Accept 응답에 사용[3]

-      JSEncKey: Rejoin-Request에 의해 트리거 된 Join-Accept를 암호화에 사용[4]

6.1.2 After Activation

활성화 후 다음의 정보들이 디바이스에 저장된다.

-      DevAddr: 디바이스 어드래스

-      NwkSEncKey, SNwkSIntKey, FNwkSIntKey

-      AppSKey

6.1.2.1 End-device address(DevAddr)

32bit의 값 DevAddr을 통해 현재 네트웤에서 디바이스를 식별한다.

 

The LoRaWAN protocol supports various network address types with different network address space sizes. The variable size AddrPrefix field is derived from the Network Server’s  unique identifier NetID (see 6.2.3) allocated by the LoRa Alliance with the exception of the  AddrPrefix values reserved for experimental/private network. The AddrPrefix field enables  the discovery of the Network Server currently managing the end-device during roaming.  Devices that do not respect this rule cannot roam between two networks because their home  Network Server cannot be found. =>여러 네트워크 주소 유형 지원, 네트워크 서버 로밍관련 내용임;

The least significant (32-N) bits, the network address (NwkAddr) of the end-device, can be arbitrarily assigned by the network manager. => NwkAddr은 네트워크 관리자가 임의로 지정

The following AddrPrefix values may be used by any private/experimental network and will not be allocated by the LoRa Aliance. => 주저리주저리

6.1.2.2 Forwarding Network session integrity key (FNwkSIntKey)

FnwkSIntKey는 세션키임, upLink의 MIC를 계산하는데 사용된다. 4.4절 참고

FNwkSIntKey는 안전하게 보관 필요

6.1.2.3 Serving Network session integrity key (SNwkSIntKey)

SNwkIntKey는 세션키임, downlink 메시지의 MIC를 계산하여 검증하는데 사용되고, upLink의 메시지 MIC 1/2를 계산하는데 사용함[5]

1.0 NS에 붙으면 6.1.2.2 6.1.2.3 키는 같은 키이다.

SNwkSIntKey는 안전하게 보관 필요

6.1.2.4 Network session encryption key (NwkSEncKey)

NwkSEncKey는 세션키임, up/down link의 MAC Command를 암/복호화하는데 사용된다. 1.0 NS에 붙으면 MAC payload 암호화와 MIC 계산에 사용된다. NwkSEncKey와 FNwkSIntKey는 같은 값

이것도 안전하게 보관 필요

6.1.2.5 Application session key (AppSKey)

AppSKey는 어플리케이션 세션키임, 어플리케이션 계층에서만 볼 수 있게 payload를 암/복호화 한다. 어플리케이션 페이로드는 단말과의 E2E보안이 됨, .BUT => but they are integrity protected only in a hop-by-hop fashion: one hop between the end-device and the Network Server, and the other hop between the Network Server and the application server. That means, a malicious Network Server may be able to alter the content of the data messages in transit, which may even help the Network Server to infer some information about the data by observing the reaction of the application end-points to the altered data.

(위의 사항이 취약점이라는데 이해 필요함.)(컨텐츠 이해 못함)

종단간 기밀성 무결성 보호를 하기위해 추가 보안 솔루션을 사용할 수 있음 ..;

6.1.2.6 Session Context

세션 컨텍스트는 NS, AS의 세션을 보관함

NS 세션은 아래와 같이 구성됨

-      N/SNwkSIntKey

-      NwkSEncKey

-      FCntUp

-      FCntDwn(LW 1.0) or NFCntDwn(LW 1.1)

-      DevAddr

AS 세션은 아래와 같이 구성됨

-      AppSKey

-      FCntUp

-      FCntDown(LW 1.0) or AFCntDwn(LW 1.1)

네트웤 세션 상태는 NS와 디바이스 끼리 관리된다. 어플리케이션 세션 상태는 AS와 디바이스끼리 관리된다.

OTAA 또는 ABP 과정이 끝나면, 새로운 보안 세션이 NS, AS, 디바이스에 수립된다. 키와 디바이스 주소는 세션 기간 동안 고정된다 (FNwkSIntKey, SNwkSIntKey, AppSKey, DevAddr). 프레임 카운터는 프레임 트래픽이 세션 기간 동안 교환 할 때 증가함 (FCntUp, FCntDwn, NFCntDwn, AFCntDwn)(이해안감).

It is RECOMMENDED that session state be maintained across power cycling of an end-device. Failure to do so for OTAA devices means the activation procedure will need to be executed on each power cycling of a device.

 

6.2 Over-the-Air Activation

OTAA의 경우, NS 송신 전 Join을 해야한다. Session context 정보가 없을 경우 매번 Join을 해야한다.

조인을 하기 전에 DevEUI, JoinEUI, NwkKey, AppKey가 있어야한다.

6.2.1 Join procedure

디바이스 관점에서, 조인은 Join/Re-Join Request/accept 메시지로 구성 되어있다.

 

6.2.2 Join-request message

디바이스가 조인 요청을 하면 조인 과정은 시작한다.

 

위의 3개 값이 전송된다.

DevNonce는 0부터 시작한다. DevNonce는 조인을 할 때마다 1씩 증가한다(다시 사용하면 안됨). DevNonce는 영구적이다(리붓해도 카운팅은 안사라짐). JoinEUI를 변경하지 않고 DevNonce를 리셋해버리면 NS는 조인 요청을 거절한다(NS는 디바이스의 Nonce를 관리함).

Note: 디바이스와 NS의 Sync 관련 설명……

조인 요청에 쓰이는 MIC 값은 아래와 같이 생성된다.

cmac = aes128_cmac(NwkKey, MHDR | JoinEUI | DevEUI | DevNonce)

MIC = cmac[0..3]

조인 요청 메시지는 암호화 안함. (데이터 송/수신 설명….) 디바이스는 JoinRequest 송신 후, DevNonce 값을 1 올림

 

6.2.3 Join-accept message

조인이 성공하면 Join accept message를 리턴한다. 네트워크 송/수신 관련 설명 ….

조인 요청이 실패하면 리턴을 안한다.

조인 억셉 메시지는 아래와 같다.

 

Downlink 파라미터는 JoinNonce, NetID, DevAddr, DLSettings이다. RxDelay, CFList 네트워크 송/수신 관련 값이다.

 JoinNonce는 FNwkSIntKey, SNwkSIntKey, NwkSEncKey, AppSKey를 생성하는데 사용된다. JoinNonce는 조인 억셉 메시지가 내려가는 순간 1 증가한다.

디바이스는 Join Nonce를 보관한다. 디바이스는 MIC 값 검증과 JoinNonce가 큰 것에 대해(자기 값보다)서만 처리해야 한다. Join accept message를 제대로 받으면 디바이스의 Join Nonce는 바뀐다.

LoRa 얼라이언스는 관리되지 않는 실험/사설망을 제외하고 24bite의 고유 네트워크 식별자(NetID)를 할당한다.

조인할 경우 OptNeg를 통해 버전을 식별하고 하위 호환성을 해소한다 라는 내용임

NwkKey를 통해 JoinAcceptMessgae를 복호호화한다. 해당 Join Nonce를 통해 아래

NwkKey를 통해 JoinAcceptMessgae를 복호화한다. 그 후, Join Nonce를 통해 아래 5가지 키를 생성하며, JSIntKey를 통해 MIC 검증을 한다.

AppSKey = aes128_encrypt(AppKey, 0x02 | JoinNonce | JoinEUI | DevNonce | pad16)

FNwkSIntKey = aes128_encrypt(NwkKey, 0x01 | JoinNonce | JoinEUI | DevNonce | pad16 )

SNwkSIntKey = aes128_encrypt(NwkKey, 0x03 | JoinNonce | JoinEUI | DevNonce | pad16)

NwkSEncKey = aes128_encrypt(NwkKey, 0x04 | JoinNonce | JoinEUI | DevNonce | pad16)

cmac = aes128_cmac(JSIntKey, JoinReqType | JoinEUI | DevNonce | MHDR | JoinNonce | NetID | DevAddr | 1610 DLSettings | RxDelay | CFList )

MIC = cmac[0..3]

 

ReJoin일 경우, 위의 그림과 같이 JSEncKey를 생성하여, 복호화 한다(JoinReqType은 헤더에?(MAC 은 검증용으로 포함하고)).

 

6.2.4 ReJoin-request message

디바이스가 Join을 하여 활성화가 되면, 주기적으로 Re-Join 할 수 있다. Re-Join 요청의 경우, 뒷단 서버와 디바이스끼리 새로운 session context를 확립할 수 있게 해준다. Re-Join은 디바이스 처리 주체를 다른 NS로 이관을 하거나, 주어진 네트워크의 디바이스 devAddr을 변경하거나 re-key를 한다.

RX1/RX2 관련 설명 중

Note: NS는 Re-join Request/Accept Messgae를 처리하는데 디바이스의 성공적인 re-join upLink가 올라오기 전까지 이전 보안 context(session context)를 유지해야한다. 모든 케이스의 re-join 요청 메시지는 Re-Join 요청은 표준 Jorin 요청 메시지와 유사하다.

Rejoin은 Rejoin Type이라는 필드로 3개의 명령을 아래와 같이 구분한다.

Rejoin Req Type	설명
0	NetID와 DevEUI를 포함한다. 라디오 파라미터를 포함한 디바이스의 모든context를 리셋한다(devAddr, session keys, frame counters, radio parameters). 이 메시지는 장치의 JoinServer가 아닌 수신 네트워크 서버에 의해서만 장치의 홈 네트워크 서버로 라우팅 될 수 있다. MIC 도.
1	JoinEUI와 DevEUI를 포함한다. 초기 Join 요청과 똑같다.
2	NetID와 DevEUI를 포함한다. Re-key와 DevAddr을 바꾼다.

 

---

[1] 해당사항에 대한 개요는 선행 연구 자료에서 확인할 것

[2] 1.0.1 버전과의 제일 큰차이점 중 하나 Join 서버 출현(그 외 여러가지 키 출현, Re-Join 출현)

[3] JSIntKey = aes128_encrypt(NwkKey, 0x06 | DevEUI | pad16)

[4] JSEncKey = aes128_encrypt(NwkKey, 0x05 | DevEUI | pad16)

[5] Uplink MIC는 FNwkSIntKey와 SNwkSIntKey 2개의 키로 완성된다. 왜냐하면: 로밍 설정에서 잔달 네트워크 서버가 MIC 필드의 절반 만 확인할 수 있기 위해서이다. >> 이해 안감