JWE 형식을 사용하는 방법

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

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

JSON 문서의 압축 직렬화 를 사용하여 JWE blob를 만듭니다. JWE blob를 만들 때 포함해야 하는 매개 변수는 다음과 같습니다.

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

  • "alg":"dir"

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

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

    이 두 가지 암호화 알고리즘을 지원합니다.

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

    이것은 독점 키와 사용할 수 있는 네 가지 값입니다. 암호화된 데이터의 목적을 대상 장치에 신호를 보내기 위해 이 키를 도입했습니다. 값은 암호화된 데이터를 사용하는 장치의 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 암호 텍스트: 이는 비밀을 유지하려는 암호화된 페이로드입니다.

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

  장치에서 수행하려는 작업에 따라 다른 유형의 페이로드가 있습니다. 다른 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 blobs를 생성하기 위한 도구가 클라이언트 비밀에서 동일한 암호화/해독 키를 파생하기 위해 동일한 절차를 따라야 한다는 것을 의미합니다.

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

• 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바이트의 무작위 시퀀스를 선택합니다. 이 예제에서는 34 b3 5d dd 5f 53 7b af 2d 92 95 83 base64url이 NLNd3V9Te68tkpWD(16진수)로 인코딩됩니다.

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의 네 번째 요소(JWE 암호 텍스트)입니다.

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

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

10. JWE blob의 5개 요소를 점(JOSEheader..IV.Ciphertext.Tag)과 연결하여 다음을 얻습니다.

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

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

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

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