[Hyperledger Indy Docs] Indy SDK: 2. Key Concepts

Indy SDK를 이해하기 위한 핵심 개념

• Revocation(해지)
  • Background: Cryptographic Accumulators(배경지식: 암호화 누산기)
  • Background: Tails Files(배경지식: Tails Files)
  • Setup(환경설정)
  • How Revocation Will Be Tested(해지 테스트 방법)
  • Preparing for Revocation at Issuance(발급시 해지 준비)
  • Presenting Proof of Non-Revocation(비 해지 증명 제시)
  • Putting It All Together(모든 것을 함께 집어넣기)
• Wallets(지갑)
  • Key Credentials(주요 Credential)
  • Cases(사례)

Revocation(해지)

이 문서는 개념적인 수준에서 Credential 해지를 설명하는 것을 목표로 합니다. 이 문서가 여전히 저수준이라고 생각되면 이 소개 비디오의 0:30에서 4:30 사이를 보는 것을 고려할수 있습니다.

 

Background: Cryptographic Accumulators(배경지식: 암호화 누산기)

매커니즘을 자세히 설명하기 전에 암호화 누산기(cryptographic accumulators)를 매우 높은 수준에서 이해해야합니다. 우리는 설명에서 어려운 수학을 피하려고 노력할 것입니다.

누산기는 여러 숫자를 곱한 곱으로 생각할 수 있습니다. 방정식 a * b * c * d = e에서 누산기는 e입니다. 각각의 새로운 요소가 곱해질 때 값을 축적합니다. 우리는 숫자를 연결할 수 있습니다. a=2, b=3, c=5, d=7이면 누산기 e의 값은 210입니다. e가 이 값을 갖는 경우 3은 인수이므로 "in" e라고 합니다. 누산기에서 3을 꺼내려면 210을 3으로 나누고 70을 얻습니다(= 2 * 5 * 7). 3은 이제 "제거"되었습니다.

a와 같은 단일 요소에 다른 모든 요소(b * c * d)의 의 곱을 곱하여 e를 생성할 수도 있습니다.

누적에 기여하는 다른 요소(이 credential의 프라이빗 요소를 제외한 모든 요소)의 결과를 증인(witness)이라고 합니다.

이것은 유용한 특성입니다. 즉, 다른 입력 값 자체가 아닌 a의 값과 다른 모든 입력의 곱을 다른 사람에게 말할 수 있으며 출력을 생성할 수 있습니다.

 

Background: Tails Files(배경지식: Tails Files)

위의 간단한 예에서는 4 가지 요소만 있으며 적은 수를 사용하고 있습니다. 또한 우리는 표준 산술을 사용하고 있습니다. 이러한 시스템에서 누산기의 내용은 간단한 소인수분해를 통해 역 엔지니어링 될 수 있습니다.

해지(revocation)에 유용하기 위해 Indy 누산기는 되돌릴 수 없습니다. 즉, 누산기 값을 도출하는 유일한 방법은 요소를 아는 것이여야합니다. 우리는 모듈식 산술(나눗셈이 정의되지 않은 경우)을 사용하고 요소에 대해 소수를 사용하여 매우 긴 정수의 증인(witness)을 수행함으로써 이를 달성합니다.

tails file은 누산기 및 해당 요소와 연관됩니다. 누산기에 대해 임의로 생성된 요소의 배열을 포함하는 이진 파일입니다. 2, 3, 7과 같은 작은 숫자 대신 이러한 요소는 화면에 편리하게 표시하기에는 너무 큰 숫자입니다. 일반적으로 tails file에서 이러한 숫자 요소의 수량은 수십만에서 수천만에 이릅니다.

tails file은 비밀이 아닙니다. 전 세계에 일반 텍스트로 게시되며 누구나 무료로 다운로드할 수 있습니다. 이 파일의 내용은 절대 바뀌지 않습니다.

특정 발행자가 발핸항 각 잠재적 또는 실제의 credential에는 tails file의 누적 요소에 대한 색인이 지정됩니다. 그러나 해지되지 않은 credential만 누산기의 값에 기여합니다. 우리는 이것이 어떻게 작동하는지 볼 것입니다.

 

Setup(환경설정)

해지 가능한 credential을 발급하기 전에 생태계에는 다음과 같은 사항이 충족되어야합니다.

1. 각 credential 유형에 대한 schema는 원장에 작성해야합니다. 예를 들어, 회사에서 고용 증명을 발행하려면 "Employee Credential" schema를 게시해야합니다. 마찬가지로, 출생 증명서 credential이 발행되기 전에, "Birth Certificate" schema가 정의되어 일반인에게 제공되어야합니다. 여러 issuer가 동일한 schema를 참조할 수 있습니다. schema는 시간이 지남에 따라 버전을 지정하고 발전시킬 수 있습니다. 모든 개인이나 기관은 원장에 schema를 작성할 수 있습니다. 이것은 특별한 권한이 필요하지 않다는 의미입니다.
2. 각 issuer는 생성하려는 각 credential 유형마다 credential definition을 원장에 게시해야합니다. 이 정의는 특정 schema와 일치하는 credential을 만들려는 issuer의 의도를 알리고 issuer가 해당 credential에 서명하는 데 사용할 키를 지정합니다. (issuer의 DID를 인증하는 데 사용되는 verkey + signing key 쌍은 credential에 서명하는 데 사용된 키와 별도로 유지되어야합니다. 따라서 각 키 쌍을 독립적으로 회전시킬 수 있습니다. sysadmin이 DID 키 쌍을 회전시키고 실수로 기관에서 발급한 모든 credential을 무효화하면 문제가 될 수 있습니다.)
3. 각 issuer는 원장에 해지 레지스트리(revocation registry)를 게시해야합니다. 이 메타 데이터는 credential definition을 참조하고 해당 credential 유형에 대한 해지를 처리하는 방법을 지정합니다. 해지 레지스트리는 해지를 테스트하는 데 사용할 수 있는 암호화 누산기(accumulator)를 알려주고 연관된 tails file의 URI 및 해시를 제공합니다.
4. 각 issuer는 모든 관련된 credential의 해지 상태를 설명하는 누산기 값을 원장에 게시해야합니다. 이 누산기는 주기적으로 또는 필요에 따라 업데이트해야합니다. 예를 들어, 운전 면허 부서에서 특정 근무일 동안 3 개의 라이센스를 취소한 후 오후 5시에 문을 닫으면 그들의 운전 면허증 credential의 누산기 값을 업데이트하는 원장 트랜잭션을 발행하여 3 개의 해지된 credential을 제거할 수 있습니다. "제거"라는 의미는 위에서 설명한 바와 같습니다. 3 개의 해지된 credential과 관련된 인덱스의 tails file에 나열된 요소가 더 이상 누산기에 곱해지지 않습니다.

 

How Revocation Will Be Tested(해지 테스트 방법)

이제 훨씬 나중에 일어날 일에 대해 생각해보도록 하겠습니다. 증명자(prover)가 검증자(verifier)에게 proof를 제공할 때, 우리는 일반적으로 그 proof를 핵심 정보 요구에 초점을 둔 것으로 생각합니다.: 생년월일은? 주소를 알려주십시오. 이것이 기본 증명(primary proof)입니다.

그러나 또 다른 차원의 증명이 필요합니다. 증명자(prover)는 기본 증명(primary proof) 뒤에 있는 credential이 해지되지 않았음을 입증해야합니다. 이것으르 비 해지 증명(proof of non-revocation)이라고 합니다.

Indy에서 proof of non-revocation는 증명자(prover)가 자신이 알고있는 누산기의 요소와 다른 모든 요소의 곱을 사용하여 credential에 대한 누산기의 값을 도출할 수 있음을 보여줌으로써 달성됩니다. 검증자(verifier)는 증명자(prover)가 정답을 산출한다는 것을 알 수 있지만(답변이 원장에 있기 때문에) 증명자(prover)가 이를 도출한 방법에 대한 특정 세부 사항을 모릅니다. issuer는 증명자(prover)를 무효로 하는 방식으로 수학 문제에 대한 정답을 변경하여 해지할 수 있습니다.

 

Preparing for Revocation at Issuance(발급시 해지 준비)

credential이 발행되면 실제 credential 파일이 holder(나중에 증명자(prover)가 될)에게 전송됩니다. 또한 issuer는 두 가지 중요한 정보를 전달합니다.

• tails file에서 이 credential에 해당하는 인덱스입니다. 이를 통해 holder는 비공개 요소(private factor)를 찾을 수 있으며, 이는 문서 상단의 누산기 배경 섹션에서 간단한 방정식으로 a에 매핑할 수 있습니다.
• 증인(witness)

 

Presenting Proof of Non-Revocation(비 해지 증명 제시)

증명자(prover)는 자신의 credential이 해지되지 않았다는 것을 증명해야 할 때, 자신의 private 요소에 증인(witness)을 곱하여 원장의 누산기 값을 도출하는 수학적인 방법을 제공할 수 있음을 보여줍니다.그녀는 실제로 자신의 private 값이 무엇인지를 밝히지 않고 이 작업을 거칩니다. 이것은 연관 관계를 피하기 위해 중요합니다.

그러나 credential이 발급된 이후에 누산기가 값을 변경한 경우 어떻게 해야합니까? 이 경우, 증인(witness)의 private 요소 횟수는 누산기와 같지 않습니다.

이는 동일한 트랜잭션의 일부로 증인(witness) 델타(delta)를 게시하기 위해 누산기의 업데이트를 요구함으로써 처리됩니다. 이것은 증명자(prover)가 어떻게 증인(witness)을 조정하여 (현재 tails file의 다른 인덱스 참조) 누산기의 현재 값과 다시 일치시키는지에 대한 방법을 알려줍니다. 증인(witness)을 업데이트하려면 증명자(prover)가(검증자(verifier) 아님) tails file을 다운로드해야합니다.

 

Putting It All Together(모든 것을 함께 집어넣기)

이 논의는 일부 세부 사항을 억제했습니다. 수학은 간단해졌으며, issuer가 여러 tails file 및 해지 레지스트리를 처리하는 방법 또는 왜 이것이 바람직한지에 대해서는 논의하지 않습니다. 그러나 메커니즘의 광범위한 흐름이 분명해야하며 이제 기능을 요약하기 쉬워졌습니다.:

• issuer는 원장의 숫자를 변경하여 해지합니다. 그들은 선택한 요소를 포함하거나 포함하지 않는 수학 문제에 대한 답변을 변경하기 때문에 단일 트랜잭션에서 원하는만큼의 credential을 해지할 수 있습니다. issuer는 해지하기 위해 다른 사람(prover 또는 verifier)에게 연락할 필요가 없습니다. 누산기 업데이트 트랜잭션이 원장에 나타나는 즉시 전 세계적으로 변경이 이루어집니다.
• 해지는 되돌릴 수 있습니다.
• 증명자(Prover)는 프라이버시 보호 방식으로 proof of non-revocation를 설명합니다. credential ID 또는 tails 인덱스와 같은 것으로 연관시킬 수 없습니다. 이것은 해지 목록 접근 방식과 근본적으로 다르며, 테스트를 위해 연관 관계가 필요합니다.
• proof of non-revocation의 검증은 매우 쉽고 저렴합니다. 검증자(verifier)에게 tails file이 필요하지 않으며 계산이 간단합니다. non-revocation을 증명하는 것은 증명자(prover)에게는 다소 비싸지만 지나치게 복잡하지는 않습니다.
• 검증자(verifier)는 issuer와 연락하거나 해지 목록을 참조하여 해지를 테스트할 필요가 없습니다.

 

Wallets(지갑)

이 실행의 목적은 indy-sdk를 위한 기본 암호화 된 지갑(wallet)을 제공하는 것입니다.

indy-sdk의 기본 지갑(wallet) 구현은 강화된 SQLCipher 버전을 사용합니다.:

• HMAC-SHA1 대신 HMAC-SHA256 사용
• PBKDF2(Password-Based Key Derivation Function)는 암호 키 데이터를 64K 대신 100K로 사용
• PBKDF2(Password-Based Key Derivation Function)는 HMAC 키 파생을 위해 2 대신 10으로 사용
• 페이지 사이즈는 1K 대신 2K 사용

 

Key Credentials(주요 Credential)

기본 지갑(wallet)을 사용하면 데이터를 암호화하는 데 선택적 암호 구(optional passphrase)를 사용할 수 있습니다. 키를 비워두거나 생략하여 암호가 제공되지 않으면 지갑(wallet)은 암호화되지 않고 SQLite3 형식으로 저장됩니다. 지갑(wallet)을 여는 암호는 indy-sdk 외부에 저장되며 HSMs, TEEs 또는 오프라인 방법과 같은 소비자의 보안 환경 설정에 따라 다릅니다.

indy-sdk는 지갑(wallet)을 열거나 생성하기 위해 JSON 매개변수로 된 credential을 지원합니다.

{
   "key": "<passphrase>"
   "rekey": "<passphrase>"
}

 

credential 매개 변수를 생략하거나 키가 빈 문자열인 경우 지갑(wallet)은 암호화되지 않은 상태로 남아있습니다.

key는 지갑(wallet)을 여는 암호이며 PBKDF2를 100K로 실행합니다.

rekey가 제공된다고 하면, key를 사용하여 지갑(wallet)이 열리고 추후의 공개 호출을 위해 암호(passphrase)를 rekey 값으로 변경할 것입니다. rekey는 기존 지갑(wallet)에만 필요하며 새 지갑(wallet)을 생성할 때에는 오류가 발생합니다.

만약 rekey에 [null, ""]이 포함되어 있으면 지갑(wallet)은 해독됩니다.

만약 key가 [null, ""]이고 rekey가 비어있지 않은 값을 포함하고 있으면 지갑(wallet)은 암호화됩니다.

참고

rekey는 key를 변경할 때에만 필요합니다. 그렇지 않은 경우에는 생략해야합니다.

 

Cases(사례)

Normal wallet / No passphrase

암호화되지 않은 지갑(wallet)을 생성하려면, credential이 비어 있거나 지정되어 있지 않아야 합니다. key는 [null,""]일 것입니다.

 

Encrypted wallet / A Key

암호화된 지갑(wallet)은 key 필드에 암호를 지정해야합니다. 암호는 공백이 아닌 값이어야합니다.

{
   "key": "Th1sIsArEALLY$3cuR3PassW0RD"
}

 

 

Normal wallet to encrypted wallet / Adding a Key

기존의 암호화되지 않은 지갑(wallet)에 암호화를 추가하려면 key를 [null,""]로 설정하고 rekey를 유효한 암호로 설정해야합니다. 그런 다음 지갑(wallet) 공개 호출은 Encrypted Wallet 섹션과 동일합니다.

{
   "key": null,
   "rekey": "il0V3MyN3WpA$SworD"
}

 

 

Encrypted wallet to normal wallet / Removing a Key

기존 암호화된 지갑(wallet)에서 암호화를 제거하려면, key를 현재 값으로 설정하고 rekey를 빈 값 [null,""]으로 설정해야합니다. 그런 다음 지갑(wallet) 공개 호출은 Normal wallet 섹션과 동일합니다.

{
   "key": "Th1sIsArEALLY$3cuR3PassW0RD",
   "rekey": null
}

 

 

Updating passphrase / Changing a Key

회전(rotating) 지갑(wallet) 비밀번호를 권장합니다. key를 현재 값으로 설정하고 rekey를 새 값으로 설정해야합니다. 그런 다음 지갑(wallet) 공개 호출은 Encrypted wallet 섹션과 동일합니다.

{
   "key": "Th1sIsArEALLY$3cuR3PassW0RD",
   "rekey": "s8c0R31tYi$hARd"
}