JWE 형식을 사용하는 방법

이 섹션에서는 JWE가 장치에 대한 입력으로 생성될 것으로 예상하는 방법을 설명하므로 인증서 및 키에서 blob를 생성하는 자체 도구를 빌드할 수 있습니다.

JSON 웹 암호화(JWE) https://datatracker.ietf.org/doc/html/rfc7516 및 JSON 웹 서명(JWS) https://datatracker.ietf.org/doc/html/rfc7515을 참조하십시오.

JSON 문서의 Compact Serialization 을 사용하여 JWE blobs를 만듭니다. JWE blobs를 만들 때 포함해야 하는 매개 변수는 다음과 같습니다.

• JOSE 헤더 (보호됨). JSON 객체 서명 및 암호화 헤더에 다음 키 값 쌍을 포함해야 합니다.

  • "alg":"디르"

    직접 알고리즘은 페이로드 암호화를 지원하는 유일한 알고리즘이며 장치의 초기 클라이언트 암호를 사용해야 합니다.

  • "enc":"A128GCM" 또는 "enc":"A256GCM"

    다음 두 개의 암호화 알고리즘을 지원합니다.

  • "cisco-action": "add" 또는 "cisco-action": "populate" 또는 "cisco-action": "activate" 또는 "cisco-action": "deactivate"

    이는 독점 키와 사용 가능한 4개의 값입니다. 암호화된 데이터의 목적을 대상 장치에 알리기 위해 이 키를 도입했습니다. 이 값은 암호화된 데이터를 사용하는 장치의 xAPI 명령을 따라 이름이 지정됩니다.

    향후 JWE 확장과의 잠재적인 충돌을 완화하기 위해 이를 cisco-action 이라고 명명했습니다.

  • "cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }

    또 다른 독점 키입니다. 제공한 값을 장치의 키 파생을 위한 입력으로 사용합니다. 버전 은 1 (키 파생 기능의 버전)이어야 합니다. 소금 의 값은 최소 4바이트의 base64 URL로 인코딩된 순서여야 하며, 반드시 무작위로 선택해야 합니다.

• JWE 암호화 키. 이 필드는 비어 있습니다. 장치는 초기 ClientSecret에서 파생됩니다.

• JWE 초기화 벡터. 페이로드를 암호 해독하려면 base64url 인코딩 초기화 벡터를 제공해야 합니다. IV는 반드시 임의의 12바이트 값이어야 합니다(IV의 길이가 12바이트여야 하는 AES-GCM 암호 제품군 사용).

• JWE AAD (추가 인증된 데이터). 이 필드는 압축 직렬화에서 지원되지 않으므로 생략해야 합니다.

• JWE 암호화 텍스트: 이는 비밀로 유지하려는 암호화된 페이로드입니다.

  페이로드가 비어 있을 수 있습니다. 예를 들어, 클라이언트 비밀을 재설정하려면 빈 값으로 덮어써야 합니다.

  장치에서 수행하려는 작업에 따라 다양한 유형의 페이로드가 있습니다. 다른 xAPI 명령어는 다른 페이로드를 예상하며, 다음과 같이 cisco-action 키를 사용하여 페이로드의 목적을 지정해야 합니다.

  • "cisco-action":"populate" 를 사용하여 암호 텍스트는 새로운 ClientSecret입니다.

  • ""cisco-action":"add" 를 사용하면 암호문은 인증서 및 개인 키(연결)를 전달하는 PEM blob입니다.

  • ""cisco-action":"activate" 암호문은 장치 ID 확인을 위해 활성화하고 있는 인증서의 지문(sha-1의 16진수 표시)입니다.

  • ""cisco-action":"deactivate" 를 사용하면 암호문은 디바이스 ID 확인에 사용되지 않는 인증서의 지문(sha-1의 16진수 표현)입니다.

• JWE 인증 태그: 이 필드에는 압축적으로 직렬화된 전체 JWE blob의 무결성을 확인하기 위한 인증 태그가 포함되어 있습니다.

암호화 키를 ClientSecret에서 도출하는 방법

암호의 첫 번째 채우기 이후에는 암호를 일반 텍스트로 수락하거나 출력하지 않습니다. 이는 장치에 액세스할 수 있는 사용자의 잠재적인 사전 공격을 방지하기 위한 것입니다.

장치 소프트웨어는 클라이언트 암호를 키 파생 기능(kdf)에 대한 입력으로 사용한 후 장치의 콘텐츠 암호 해독/암호화에 파생된 키를 사용합니다.

따라서 JWE blob를 생성하는 도구는 동일한 절차에 따라 클라이언트 암호에서 동일한 암호화/암호 해독 키를 파생시켜야 합니다.

장치는 다음 파라미터와 함께 키 파생( 참조)에 https://en.wikipedia.org/wiki/Scryptscrypt를 사용합니다.

• CostFactor(N)는 32768

• BlockSizeFactor(r)는 8

• ParallelizationFactor(p)는 1

• 소금은 최소 4바이트의 임의 시퀀스입니다. cisco-kdf 매개 변수를 지정할 때 이 동일한 소금 을 제공해야 합니다.

• 키 길이는 16바이트(AES-GCM 128 알고리즘을 선택한 경우) 또는 32바이트(AES-GCM 256 알고리즘을 선택한 경우)입니다.

• 최대 메모리 캡은 64MB

이 파라미터 세트는 장치의 키 파생 기능과 호환되는 scrypt의 유일한 구성입니다. 장치의 이 kdf를 "version":"1"이라고 하며, 이는 현재 cisco-kdf 매개 변수가 사용하는 유일한 버전입니다.

작동 예제

다음은 JWE 암호화 프로세스가 장치에서 생성한 프로세스와 동일하게 작동하는지 확인하기 위해 따를 수 있는 예제입니다.

예제 시나리오는 PEM blob를 장치에 추가하는 것입니다(전체 인증서와 키 대신 매우 짧은 문자열로 인증서 추가 모방). 예제의 클라이언트 비밀은 ossifrage입니다.

1. 암호화 암호를 선택합니다. 이 예에서는 A128GCM (갈루아 카운터 모드에서 128비트 키를 사용하는 AES)을 사용합니다. 원하는 경우 도구는 A256GCM 을 사용할 수 있습니다.

2. 솔트(최소 4바이트의 무작위 시퀀스여야 함)를 선택합니다. 이 예제에서는 (16진수 바이트)E5 E6 53 08 03 F8 33 F6를 사용합니다. Base64url은 시퀀스를 인코딩하여 5eZTCAP4M_Y 를 얻습니다(base64 패딩 제거).

3. 다음은 콘텐츠 암호화 키(cek)를 생성하기 위한 샘플 scrypt 통화입니다.

   cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)

   파생된 키는 다음과 같이 16바이트(16진수)여야 합니다.95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac base64url이 lZ66bdEiAQV4_mqdInj_rA에 인코딩됩니다.

4. 초기화 벡터로 사용할 12바이트의 무작위 시퀀스를 선택합니다. 이 예제에서는 (16진수) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 을 사용하여 base64url이 NLNd3V9Te68tkpWD에 인코딩합니다.

5. 압축 직렬화를 사용하여 JOSE 헤더를 생성하고(여기서 사용하는 것과 동일한 파라미터 순서를 따름) base64url로 인코딩합니다.

   {"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}

   base64url 인코딩된 JOSE 헤더는 eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

   이는 JWE blob의 첫 번째 요소가 됩니다.

6. JWE 암호화 키를 제공하지 않기 때문에 JWE blob의 두 번째 요소는 비어 있습니다.

7. JWE blob의 세 번째 요소는 초기화 벡터 NLNd3V9Te68tkpWD입니다.

8. JWE 암호화 도구를 사용하여 암호화된 페이로드 및 태그를 생성합니다. 이 예제에서 암호화되지 않은 페이로드는 가짜 PEM blob가 됩니다. 이는 PEM 파일

   사용해야 하는 암호화 파라미터는 다음과 같습니다.

   • 페이로드는 PEM 파일입니다.

   • 암호화 암호는 AES 128 GCM입니다

   • AAD(추가 인증 데이터)로서 base64url로 인코딩된 JOSE 헤더

   Base64url은 암호화된 페이로드를 인코딩합니다. 그러면 f5lLVuWNfKfmzYCo1YJfODhQ

   이는 JWE blob의 4번째 요소(JWE 암호문)입니다.

9. Base64url은 8단계에서 생성한 태그를 인코딩합니다. 그러면 PE-wDFWGXFFBeo928cfZ1Q

   이는 JWE blob의 5번째 요소입니다.

10. JWE blob의 5가지 요소를 도트(JOSEheader..IV.Ciphertext.Tag)와 연결하여 다음을 얻습니다.

    JhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

11. 여기에 표시된 것과 동일한 base64url로 인코딩된 값을 파생한 경우 자체 도구를 사용하면 E2E 암호화 및 장치의 확인된 ID를 보호할 준비가 된 것입니다.

12. 이 예제는 실제로 작동하지 않지만 원칙적으로 다음 단계는 인증서를 추가하는 장치의 xcommand에 대한 입력으로 위에서 생성한 JWE blob를 사용합니다.

    xCommand 보안 인증서 추가 eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q