JWE 형식을 사용하는 방법

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

참조 JSON 웹 암호화(JWE)https://datatracker.ietf.org/doc/html/rfc7516그리고 JSON 웹 서명(JWS)https://datatracker.ietf.org/doc/html/rfc7515.

우리는 사용 컴팩트 직렬화 JWE Blob을 생성하기 위한 JSON 문서. JWE Blob을 만들 때 포함해야 하는 매개 변수는 다음과 같습니다.

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

  • "alg":"dir"

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

  • "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" }

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

• JWE 암호화된 키. 이 필드는 비어 있습니다. 장치는 파생 ClientSecret.

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

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

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

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

  장치에서 수행하려는 작업에 따라 다양한 유형의 페이로드가 있습니다. 다른 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바이트의 무작위 시퀀스입니다. 파라미터를 지정할 때 salt 동일하게 제공해야 cisco-kdf 합니다.

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

• 최대 메모리 캡은 64MB

이 파라미터 세트는 장치의 키 파생 기능과 호환되는 scrypt의 유일한 구성입니다. 장치의 이 kdf가 호출되며 "version":"1" 현재 파라미터에서 사용되는 유일한 cisco-kdf 합니다.

작동 예제

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

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

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

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

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

   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가 됩니다 this is a PEM file

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

   • 페이로드: this is a PEM file

   • 암호화 암호는 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)와 연결하여 다음을 얻습니다.

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

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

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

    xCommand Security Certificates Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q