피드백을 보내 주셔서 감사합니다.

JWE 형식을 사용하는 방법

이 섹션에서는 인증서와 키로 얼룩을 생성하는 도구를 직접 만들 수 있도록 JWE가 장치 입력으로 생성되는 방식을 설명해요.

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

우리는 JWE 블럽을 만들 때 JSON 문서의 컴팩트 직렬화를 사용해요. JWE 블롭을 만들 때 포함해야 하는 매개변수는 다음과 같아요.

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

  • “alg”: “디렉토리”

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

  • “enc”: "A128GCM” 아니면 “enc”: "A256GCM”

    우리는 이 두 암호화 알고리즘을 지원해요.

  • “시스코 액션”: “추가” 또는 “시스코 액션”: “채우기” 또는 “시스코 액션”: “활성화” 또는 “시스코 액션”: “비활성화”

    이것은 독점 키이고 네 가지 값을 사용할 수 있어요. 암호화된 데이터의 목적을 대상 장치에 알리기 위해 이 키를 도입했어요. 값의 이름은 암호화된 데이터를 사용하는 장치의 xAPI 명령 이름을 따서 지었어요.

    향후 JWE 확장과의 잠재적 충돌을 완화하기 위해 시스코 액션이라는 이름을 붙였어요.

  • “cisco-kdf”: {“버전”: “1", “솔트”: “베이스64 URL은 4바이트 이상을 무작위로 인코딩했어요”}

    또 다른 독점 키예요. 우리는 당신이 제공한 값을 기기에서 키 도출을 위한 입력으로 사용해요. 버전은 1이어야 해요 (키 파생 함수 버전). 솔트 값은 4바이트 이상의 base64 URL 인코딩 시퀀스여야 해요. 무작위로 선택해야 해요.

• JWE 암호화 키예요. 이 필드는 비어 있어요. 기기가 초기 클라이언트 시크릿에서 파생돼요.

• JWE 초기화 벡터. 페이로드 암호 해독을 위해 base64url로 인코딩된 초기화 벡터를 제공해야 해요. IV는 무작위 12바이트 값이어야 해요 (저희는 IV의 길이가 12바이트여야 하는 AES-GCM 암호 제품군을 사용하고 있어요).

• JWE AAD (추가 인증 데이터). 컴팩트 시리얼라이제이션에서는 지원되지 않으므로 이 필드를 생략해야 해요.

• JWE 암호문: 비밀로 유지하고 싶은 암호화된 페이로드예요.

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

  기기에서 무엇을 하려고 하느냐에 따라 페이로드의 종류가 달라요. xAPI 명령어마다 예상하는 페이로드가 다르기 때문에 다음과 같이 cisco-action 키로 페이로드의 목적을 지정해야 해요.

  • “시스코 액션”: “채우기”를 사용하면 암호문이 새 클라이언트 비밀이에요.

  • ““cisco-action”: “add”를 붙이면 암호문은 인증서와 개인 키 (연결) 를 담는 PEM 블롭이에요.

  • ““cisco-action”: “activate”하면 암호문은 장치 ID 확인을 위해 활성화하는 인증서의 지문 (sha-1의 16진수 표현) 이에요.

  • ““cisco-action”: "deactivate” 사용 시 암호문은 장치 ID 확인에 사용되지 않도록 비활성화하려는 인증서의 지문 (sha-1의 16진수 표현) 이에요.

• JWE 인증 태그: 이 필드에는 JWE 컴팩트 시리얼라이즈드 블럽 전체의 무결성을 확인하기 위한 인증 태그가 들어 있어요.

클라이언트 비밀에서 암호화 키를 도출하는 방법

비밀을 처음 채운 후에는 비밀을 일반 텍스트로 받아들이거나 출력하지 않아요. 이는 기기에 접근할 수 있는 사람의 잠재적인 사전 공격을 방지하기 위한 거예요.

디바이스 소프트웨어가 클라이언트 암호를 키 파생 함수 (kdf) 의 입력으로 사용한 다음 파생된 키를 장치의 콘텐츠 암호 해독/암호화에 사용해요.

이것이 당신에게 의미하는 바는 JWE 블롭을 만드는 도구가 동일한 절차를 따라 클라이언트 암호에서 동일한 암호화/암호 해독 키를 도출해야 한다는 뜻이에요.

장치들은 다음 파라미터와 함께 키 도출을 위해 scrypt를 사용해요 (https://en.wikipedia.org/wiki/Scrypt 참조).

• 코스트 팩터 (N) 는 32768이에요.

• 블록 크기 계수는 8이에요.

• 병렬화 계수 (p) 는 1이에요.

• 솔트는 최소 4바이트의 무작위 시퀀스예요. cisco-kdf 매개 변수를 지정할 때 이와 동일한 솔트를 입력해야 해요.

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

• 최대 메모리 상한은 64MB예요

이 파라미터 세트가 장치의 키 파생 함수와 호환되는 유일한 스크립트 구성이에요. 장치에 있는 이 kdf는 “버전”:"1"이라고 불리는데, 현재 cisco-kdf 매개변수로 사용하는 유일한 버전이에요.

작업 예시

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

예제 시나리오는 장치에 PEM Blob을 추가하는 거예요 (전체 인증서 + 키 대신 아주 짧은 문자열을 사용하여 인증서를 추가하는 것과 비슷합니다). 예시의 고객 비밀은 오시프라게예요.

1. 암호화 암호 선택해요. 이 예시는 A128GCM (갈루아 카운터 모드의 128비트 키가 있는 AES) 를 사용해요. 원하시면 도구에 A256GCM 쓰셔도 돼요.

2. 솔트를 선택하세요 (최소 4바이트의 무작위 시퀀스여야 함). 이 예시는 (16진수 바이트) E5 E6 53 08 03 F8 33 F6을 사용해요. 베이스64 URL은 시퀀스를 인코딩해서 5ezTCap4m_y를 가져와요 (base64 패딩 제거).

3. 다음은 콘텐츠 암호화 키 (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을 사용해요. 베이스 64url은 nlnd3v9te68TKPWD로 인코딩해요.

5. 간결한 직렬화로 JOSE 헤더를 만든 다음 (여기서 사용하는 것과 같은 매개변수 순서를 따름) base64url로 인코드하세요.

   {"alg”: "dir”, "시스코 액션”: “추가”, "시스코-kdf”: {"salt”: "5eztCap4m_y”, "버전”: "1"}, "enc”: "A128GCM "}

   base64url로 인코딩된 JOSE 헤더는 eyjhbgcioijkaxiilcjjaxnjby1hy3RPB24ioijhzgqilcjjaxnjby1rzgyionsic2fsdci6jvlrdqva0tv9ziiwidmvyc2lvBII6IJEIQSWIZW5JIJOIQTEYO EDDTSJ9

   이것이 JWE 블롭의 첫 번째 요소가 될 거예요.

6. JWE 암호화 키를 제공하지 않아서 JWE BLOB의 두 번째 요소가 비어 있어요.

7. JWE 블럽의 세 번째 요소는 초기화 벡터 nlnd3v9te68TKPWD예요.

8. JWE 암호화 도구를 사용하여 암호화된 페이로드와 태그를 생성하세요. 이 예를 들자면, 암호화되지 않은 페이로드는 가짜 PEM 얼룩이 될 거예요. 이것은 PEM 파일이에요.

   사용해야 하는 암호화 매개변수는 다음과 같아요.

   • 페이로드는 이게 PEM 파일이에요

   • 암호화 암호는 AES 128 GCM이에요.

   • 베이스64 URL은 JOSE 헤더를 추가 인증 데이터 (AAD) 로 인코딩했어요

   Base64 URL은 암호화된 페이로드를 인코딩해요. 그러면 F5LLVuwnFKFMzyco1YJFODHQ가 출력돼요.

   이것이 JWE 블롭의 네 번째 요소 (JWE 암호문) 예요.

9. 베이스64 URL은 8단계에서 생성한 태그를 인코딩해요. 그러면 PE-WDFWWGXFBEO928CFZ1Q가 출력돼요.

   이게 JWE 블롭의 다섯 번째 요소예요.

10. JWE 블롭의 다섯 가지 요소를 점 (JoseHeader.. iv.CipherText.tag) 으로 연결하여 다음을 얻으세요.

    eyjhbgcioijkaxiilcjjaxnjby1hy3RPB24 ioijhzgqilcjjaxnjby1rzgyionsic2fsdci6 jvlwlrdqva0tv9ziiwidmvyc2 lvbii6 IJEIFSWIZW5JIJOIQTEYODDTSJ.. 9nlnd3V9TE68TKPWD.F5LLVUWNFKFMZYCO1YJFODHQ.PE-WDFWGXFBEO928CFZ1Q

11. 여기에 표시된 것과 동일한 base64url로 인코딩된 값을 자신의 도구를 사용하여 도출했다면 이를 사용하여 장치의 E2E 암호화와 확인된 ID를 보호할 수 있습니다.

12. 이 예제는 실제로 효과가 없겠지만 원칙적으로는 다음 단계는 위에서 만든 JWE blob을 인증서를 추가하는 장치의 명령 입력으로 사용하는 거예요.

    xCommand Security Certificate 추가 EYJHBGCIOIKAXNJBY1H3RPB24IOIHZGQILCJAxnjby1rzgyionsic2fsdci6jvlwlrdqva0tv9ziiiWIDMVYC2 IJEIFSWIZW5JIJOIQTEYODTSJ.. 9nLND3V9TE68TKPWD.F5LLVUWNFKFMZYCO1YJFODHQ.PE-WDFWGXFBEO928CFZ1Q