SSI에 대해 맥락을 알아보기 위해 자기주권신원을 읽으며 정리해 보았다!

VC (Verifiable Credential)

특징

• VC는 변조 감지를 제공하는 발급자가 삽입한 암호화 방식의 proof 속성을 가지고 있기 때문에 발급자에서부터 중간 스토리지 지갑을 통해 검증자에게 이르기까지 보호
• VC는 전송 중에 TLS와 같은 암호화된 통신 링크를 통해서만 전송하여 기밀로 보호되어야 한다.
• VC는 발급자 또는 다른 제 3자와의 통신이 검증자에게 전송될 필요가 없기 때문에 보유자의 장치에 저장되어 있는 경우 고가용성을 갖는다.
• VC는 검증자가 서비스 제공에 필수적인 주체 속성만 요청할 수 있도록 하여 최소 권한의 보안 속성을 용이하게 한다.
• VC는 영지식 증명(ZKP) VC 또는 원자 VC 집합을 발급하는 밝듭자의 선택적 공개를 통하여 개인정보 보호를 제공하며 이를 통해 보유자는 검증자가 필요로 하는 속성만 공개할 수 있으며, 그 이상은 공개할 필요가 없다.
• VC는 신원의 이름이 아닌 가명 ID를 통해 주체를 식별하여 주체의 개인정보를 보호한다. 이러한 가명 ID들이 주체와 검증자 사이에 쌍을 이루어 연결되는 경우에는 전역적으로 고유한 관련성은 생성되지 않는다.
• 검증자는 서비스에 접근할 수 있는 사용자의 ID가 아니라 서비스에 접근하는 데 필요한 역할이나 속성만 지정하면 되므로 VC는 유연한 역할 기반 및 속성 기반 접근 제어를 지원한다.

VC (Verifiable Credential) 구성 요소

• @context : 해당 VC가 구성하는데 사용된 정보의 집합이며 하나 이사으이 URI시퀀스로 구성
• type : 어떤 속성의 VC인지 설명하는 URI목록이 포함된다.
• id : 발급자가 생성한 VC의 고유한 식별자이며 단일 URI로 구성
• issuer : 발급자를 고유하게 식별하는 URI이며 해당 URI는 발급자의 DID 혹은 DNS의 이름을 포함할 수 있다. 검증 가능한 데이터 저장소는 발급자에 대한 X.509 공개 키 인증서와 같은 추가 세부사항을 포함 가능
• credentialSubject : 발급자가 주체에 대하여 만든 클레임 항목들이며 주체의 ID와 발급자가 주체에 대해 주장하는 속성들의 집합.
• proof : 발급자가 VC를 발급했으며 발급 이후 변조되지 않았음을 암호화 방식으로 증명하는 항목으로, 일반적으로 VC데이터 모델 사항에서 proof로 참조되는 서명이 필요. 해당 항목에 대한 단일 표준은 없으나, 증명의 유형을 나타내는 type항목이 포함되어야 함
• issuanceDate : ISO 8601형식으로 조합되었으며 VC의 발급 시점
• credentialStatus: VC의 현재 상태에 대한 세부 정보이며 표준 형식은 없지만 모든 상태에는 id, type이 포함되어야 함.
• refreshService: 발급자가 현재 VC를 새로 고치거나 업데이트하는 방법에 대한 세부 정보를 제공 및 제어할 수 있으며, 보유자만 알기를 원한다면, VC에 추가하는 방법이 아닌 VC를 캡슐화하는 VP에 추가해야 함.
• termsOfUse : VC에 이용 약관을 추가하는 표준 방법
• evidence : 발급자는 해당 항목을 VC에 추가하여 검증자가 VC의 클레임에 대해 가질 수 있는 신뢰 수준을 결정하는데 도움을 줄 수 있으며 해당 항목은 type이 포함 되어야 함.ㅌㅌ

//JSON-LD로 인코딩된 VC
{
    "@context": [
        "https://www.w.org/2018/credentials/Vl",
        "https://example.org/examples/vI"
        ],
     "id": "http://example.edu/credentials/3732",
    "type": ['VerifiableCredential", "UniversityDegreeCredential"],
    "issuer": "https: //example.edu/issuers/14",
    "issuanceDate": "2010-01-01719:23:24Z",
    "credentialSubject": {
        "id": "did: example: ebfeb1f712ebc6f1c276e12ec21",
        "degree": {
            "type": "BachelorDegree",
            "name": "Bachelor of Science in Mechanical Engineering"
        }, 
        "credentialSchema": {
            "id": "https://example.org/examples/degree.json",
            "type": "JsonSchemaValidator2018"
        },
        "termsOfUse": {
            "type": "IssuerPolicy",
            "id": "http: //example.com/policies/credential/4",
            "profile": "http://example.com/profiles/credential",
            "prohibition": [{
                "assigner": "https: //example.edu/issuers/14",
                "assignee": "AllVerifiers",
                "target": "http://example.edu/credentials/3732",
                "action": ["Archival"]
            }]
        },
        "evidence": [{
            "id": "Ittps://example.edu/evidence/f2aeec97-fcod-42bf-8ca7-0548192d4231",
            "type": ['DocumentVerification"],
            "verifier": "https: / /example.edu/issuers/14",
            "evidenceDocument": "DriversLicense",
            "subjectPresence": "Physical",
            "documentPresence": "Physical"
            }, {
            "id": "https: //example.edu/evidence/faeec97-fcod-42bf-8ca7-0548192dxyzab",
            "type": ["SupportingActivity"],
            "verifier": "https: //example.edu/issuers/14"
            "evidenceDocument": "Fluid Dynamics Focus"
            "subjectPresence": "Digital"
            "documentPresence": "Digital"
            }], 
        "refreshService": {
            "id": "https: //example.edu/refresh/3732",
            "type": "ManualRefreshService2018"
            }, 
        "proof": {
            "type": "RsaSignature2018",
            "created": "2018-06-1821:19:10Z",
            "verificationMethod": "https: //example.com/jdoe/keys/1",
            "nonce": "cOaelc8e-c7e7-469f-b252-86e6a0e7387e",
            "signatureValue": "BavEll0/IlzpYw8XNilbgVg/s...WJT24 = "
    }
}

DID (Decentralized Identifiers)

개념적 수준: DID

리소스를 식별하는 문자열인 글로벌 고유 식별자

URL 또는 URN중 어느 하나가 될 수 있으며 DID로 식별되는 리소스에 대한 표준화된 정보인 메타데이터의 집합을 얻기 위해 리졸브할 수 있는 URI

• URL (Uniform Resource Locator) :인터넷 상의 리소스를 식별하는 데 사용되는 문자열, 일반적으로 웹 페이지, 이미지, 동영상 등의 파일의 위치를 식별하는 데 사용
• URN (Uniform Resource Name) : 인터넷 상의 리소스를 고유하게 식별하는 데 사용되는 문자열이며 URN은 일반적으로 파일의 위치를 식별하지 않고, 파일 자체에 대한 식별자로 사용
• URI (Uniform Resource Identifier) : 인터넷 상의 리소스를 식별하는 데 사용되는 모든 문자열이며 URI는 URL과 URN을 모두 포함

핵심 속성

• 영구 식별자 : 변경할 필요가 없음
• 리졸브 가능한 식별자 : 메타데이터를 찾기 위해 검색 가능
• 암호로 검증 가능한 식별자 : 암호화를 사용하여 제어를 증명할 수 있음
• 분산 식별자 : 중앙형 등록 권한이 필요하지 않음

기능적 수준 : DID 작동 방식

DID Document

DID를 기본 구성 요소로 사용하는 디지털 지갑, 에이전트 또는 암호화된 데이터 저장소와 같은 디지털 ID 응용 프로그램 또는 서비스에서 사용하도록 설계된 기계 판독 가능 문서

#인증을 위한 하나의 공개 키와 하나의 서비스가 있는 DID Document예시
{
    "@context": "https: //www.w.org/ns/did/vl",
    "id": "did: example: 123456789abcdefghi",
    "authentication": [{
        "id": "did: example: 123456789abcdefghi#keys-1",
        "type": "Ed25519VerificationKey2018"
        "controller": "did: example: 123456789abcdefghi",
        "publicKeyBase58" : "H3C2AVVLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }], 
    "service": [{
        "id": "did: example: 123456789abcdefghi#vcs",
        "type": "VerifiableCredentialService",
        "serviceEndpoint": "https://example.com/vc/"
    }]
}

DID 메서드

DID를 생성하는 데 사용되는 식별자이며 ,DID 생성될 때 사용되는 식별자 및 프로토콜을 정의

#5가지 다른 DID 메서드를 사용하여 생성된 DID
# Sorvin
did:sov:WRfXPg8dantKVubE3HX8pw
# BitCoin
did:btcr:xz35-jzv2-qqs2-9wjt
# VerseOne
did:v1:test:nym: 3AEJTDMSXDDQpyUftjuoeZ2Bazp4Bswjice7FJGybcUu 
# Ethereum
did:ethr:OXE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6
# Jolocom
did:J010:11b3523535124865104b4079c04c3666627fcf5a167d69309fc84b75964e2

DID 레졸루션

DID와 관련된 DID Document를 얻는 과정이며 이 과정을 통해 DID지원 응용 프로그램 및 서비스는 DID Document에 표현된 DID 서브젝트에 대한 메타데이터를 검색 가능하며 메타데이터는 다음과 같은 DID서브젝트와의 추가 상호작용에 사용

• 검증 가능한 자격증명 발급자의 디지털 서명을 검증하기 위한 공개 키 조회
• 컨트롤러가 웹사이트나 앱에 로그인해야할 때 DID 컨트롤러와 관련된 잘 알려진 서비스 검색 및 접근
• DID 컨트롤러와 DID간 연결 요청

DID URL

DID와 관련된 추가 리소스에 대한 식별자 공간을 활성화

did:example:1234#keys-1
// 프레그먼트가 있는 DID URL이며 DID의 관련 DID Document 내에서 특정 공개키를 식별한다.
// 프레그먼트가 있는 http: 또는 https:URL이 HTML 웹페이지 내 특정 책갈피를 가리킬수 있는 방법과 유사

did:example:1234?version-id=4
// DID 매개변수가 있는 DID URL이며 최신 버전이 아닌 DID관련 DID Documnet의 이전 버전을 식별
// DID 문서의 내용이 업데이트 되었지만 특정 버전에 대한 안정적인 참조가 필요한 경우에 유용

did:example:1234?version-id=4#key-1
// 위에 두개의 DID URL을 조합한 것이며 DID관련 DID Document의 특정 이전 버전에내에서 특정 공개키 식별

did:example:1234/my/path?query#fragment
// 경로, 질의 문자열 및 프래그먼트가 있는 DID URL이며, 이 DID URL의 의미 및 처리 규칙은 핵심 DID
// 표준에 의해 정의되지 않고 DID 메서드 및 DID URL을 사용하는 애플리케이션에 따라 정의

did:example:1234?service=hub/my/path?query#fragment
// DID 매개변수가 있는 DID URL이며 DID의 관련 DID Document내에서 특정 서비스를 식별
// 나머지 구문 구성요소의 의미 및 처리 규칙은 핵심 DID 표준에 의해 정의되지 않고 서비스에 한정

DNS와 DID 비교

아키텍쳐 수준: DID가 작동하는 이유

공개 키 기반구조의 핵심 문제

공개 키 / 비밀 키는 위조될 수 없도록 서로 연결되어 있으나, 공개 키를 신뢰하는 당사자들이 실제 컨트롤러와 상호작용하고 있는지 확인할 수 있도록 공개 키를 컨트롤러에 어떻게 강력하게 바인딩 할 것인가

실제로는 컨트롤러에 식별자를 추가하여 공개 키를 컨트롤러에 바인딩을 하는 방법으로 PKI는 사용되고 있다. 그러나 아래와 같은 그림에서 보이듯 문제 지점은 여전히 남아 있다

문제점은 다음과 같다

1. 식별자를 컨트롤러에 어떻게 강력하게 바인딩할 것인가? ⇒ 식별자-컨트롤러 바인딩 문제
2. 공개 키를 식별자에 어떻게 강력하게 바인딩할 것인가? ⇒ 공개 키-식별자 바인딩 문제

솔루션1: 기존 PKI

• 식별자-컨트롤러 바인딩 문제

  → 가장 적합한 기존 식별자 중 하나를 사용하여 식별자를 컨트롤러에 강력하게 바인딩하는 것

  • 문제점
    • homographic attack(동형 문자 공격, 유사한 이름 또는 다른 구겢 알파벳의 유사 문자 사용)
    • DNS 포이즈닝 (DNS서비스에 조작된 쿼리를 전송하여 주소 정보를 변조)

• 공개키-식별자 바인딩 문제

  → 공개 키와 식별자를 모두 포함하는 문서에 대지털 서명을 하는 암호화를 사용

  • 문제점
    • 인증서에 서명을 하는 주체에 대한 중앙화된 인증기관

솔루션2: 신뢰의 웹 모델

기존 PKI의 단점중 하나인 중앙 기관(CA)에 의존하지 않는 P2P 디지털 인증서를 효과적으로 만들 수 있는 솔루션이나, 신뢰할 수 있는 경로를 어떻게 찾을 것인가에 대한 문제에 대해 합리적으로 안전하고 확장 가능하며 채택 가능한 솔루션은 아직 없다.

솔루션3: 공개 키 기반 식별자

컨트롤러에 대한 기존 식별자를 재사용한 후 공개키에 바인딩하는 대신 프로세스를 역순으로 수행하여 분산원장 또는 유사한 시스템을 이용해 공개 키를 기반으로 컨트롤러에 대한 식별자를 생성하는 방법으로 컨트롤러가 실제 PKI 신뢰 삼각형의 세 지점을 모두 제어할 수 있도록 하는 방법이지만, 컨트롤러의 식별자가 공개 키가 순환될 때마다 변경되는 점으로 인하여 키순환을 지원할 수 없기 때문에 PKI의 대안으로 채택되지 못했다.

솔루션4: DID, DID Document

공개 키 기반의 솔루션 기반으로, 키순환을 해야할 때 컨트롤러는 업데이트 된 DID Document를 생성하고 이전 개인 키를 이용해 서명한다 이를 통해 키순환 지원 및 중앙기관(CA)에 대한 단점을 개선한다.

PKI를 능가하는 DID 장점

• 후견 및 통제권
• 서비스 엔드포인트 검색
• DID간의 연결 : Diffe-hellman Key Exchange기반 프로토콜을 이용하여 P2P로 직접 교환

| Property | Description |
| --- | --- |
| 영구적 | 한 쪽 또는 양쪽 당사자가 원하지 않는 한 연결이 끊어지지 않는다. |
| 비공개적 | 연결을 통한 모든 통신은 자동으로 암호화 되고 DID의 개인 키로 디지털 서명 가능 |
| 종단간(End-to-End) | 연결에 중개자가 없다 |
| 신뢰성 | 연결은 검증 가능한 자격증명 교환을 지원하여 모든 관련 보증 수준에서 더 높은 신뢰를 구축한다. |
| 확장성 | 연결은 DID Comm 프로토콜 또는 두 에이전트가 모두 지원하는 기타 프로토콜을 통해 안전하고 비공개적이며 안정적인 디지털 통신이 필요한 모든 프로그램에서 사용 |

• 적합한 개인정보보호 중심 설계

의미 수준: DID가 의미하는 것

주소의 의미

주소는 자체적으로 존재하지 않으며 그것들을 사용하는 네트워크의 컨텍스트 안에서만 존재한다.

DID 네트워크와 디지털 신뢰 생태계

DID는 각 레이어에 다음과 같은 스택이 필수적

• Layer1: 퍼블릭 DID 유틸리티 : 퍼블릭 블록체인 과 같은 분산 원장 또는 분산파일 시스템에 게시된 DID는 모든 상위 계층의 참가자에 대해 공개적으로 검증 가능한 신뢰 루트역할을 할 수 있기 때문에 신뢰 계층의 기반을 형성
• Layer2: DID Comm : DID Comm은 DID로 식별되는 에이전트 간의 P2P 프로토콜이며 Layer2에 존재한다. 그러나 Layer1의 퍼블릭 DID도 사용 가능
• Layer3: 자격증명 교환 : DID는 디지털 서명된 검증 가능한 자격증명을 발급 및 검증하는 프로세스와 자격증명 교환 프로토콜에 대한 서비스 엔드포인트 URL 검색에 필수적
• Layer4: 디지털 신뢰 생태계 : DID는 모든 규모와 형태 또한 그들이 지정한 참가자들의 디지털 신뢰 생태계를 위한 거버넌스 기관 및 거버넌스 프레임워크의 발견과 검증을 위한 기준점으로 검증 가능한 자격증명이 발급된 거버넌스 프레임워크를 지속적으로 참조하고 거버넌스 프레임워크가 상호 운용성을 위해 서로를 참조할 수 있도록 한다.

DID Wallet & Agent

디지털 지갑

디지털 지갑은 지갑의 컨트롤러가 암호화 key, 기밀 정보 및 기타 민감한 개인 데이터를 생성. 저장, 관리 및 보호할 수 있도록 하는 소프트웨어로 구성

디지털 에이전트

디지털 에이전트는 디지털 지갑에 있어 컴퓨터나 스마트폰의 운영 체제에 해당한다 개인이 행동을 하고, 통신하며, 정보를 저장하고, 디지털 지갑의 사용을 추적할 수 있게 해주는 소프트웨어

DPKI (Decentralized Public Key Infrastructure)

KERI (Key Event Receipt Infrastructure)

거래의 유효성을 검증하고 거래가 일어날 때마다 거래 내용을 기록하여 거래 내용의 무결성과 불변성을 보장하기 위한 기술

키 관리 아키텍처의 출발점: 신뢰 루트

키 관리 아키텍처가 중앙형, 연합형, 분산형이든 상관없이 모두 신뢰 루트에서 시작

• 관리 기반 신뢰 루트(administrative roots of trust) : 기존 PKI에서 사용되는 신뢰 루트이며 발급하는 디지털 인증서의 무결성을 보장하기 위해 엄격한 절차를 따르는 사람으로 구성된 인증기관(CA)를 의미
• 알고리즘 기반 신뢰 루트(algorithmic root trust) : 트랜잭션 기반 신뢰 루트(transactional roots of trust)라고도 하며 단일 당사자가 제어할 수 없지만 모든 당사자가 공유된 신뢰의 근원에 동의할 수 있는 보안시스템을 생성하도록 설계된 컴퓨터 알고리즘을 기반 신뢰 루트를 의미
• 자체 인증 신뢰 루트 : 지율 신뢰 루트라고도 하며, 보안 난수 생성 및 암호화에 기반한 신뢰 루트를 의미. SSI의 경우 디지털 지갑만으로 생성할 수 있는 DID를 의미한다.

DKMS (Decentralized Key Management System)

DKMS란 분산 키 관리 시스템을 의미. 중앙형 권한이 없는 블록체인 및 DLT(분산원장기술)과 함께사용하기 위한 암호화 키 관리 시스템이며 기존 PKI(Public Key Infrasturcture)아키텍처의 핵심가정인 공개 키 인증서가 중앙형 또는 연합형 인증 기관인 CA에서 발급될 것이라는 가정을 없앤다.

DKMS의 장점

• 단일 실패 지점 없음 : 알고리즘 또는 자체 인증 신뢰루트를 사용하므로 중앙CA 혹은 기타 등록 기관에 의존하지 않는다
• 상호 운용성 : 두 명의 ID 소유자와 해당 애플리케이션이 독점 소프트웨어, 서비스 제공업체 또는 연합에 의존하지 않고 키 교환을 수행 및 암호화된 P2P연결을 생성 가능하다.
• 이식성 : 사용자는 DKMS호환 지갑, 에이전트 또는 에이전시의 특정 구현에 종속되는 것을 피할 수 있다.
• 키 복구 : DKMS를 이용하면 에이전트 자동 암호화 백업, DKMS 키 에스크로 서비스 및 키의 소셜 복구를 포함한 강력한 기 복구가 인프라에 직접 구축되어야 한다.

DKMS가 해결해야할 문제

• 키를 교체할 수 있는 외부 기관이 있는 경우 해당 기관에사 항상 사용자의 키를 빼앗거나 해당 시스템이 손상되어 키에 침입할 수 있다. 그래서 DKMS에는 “비밀번호 재설정” 옵션이란 없으며 DKMS는 처음부터 키 보유자를 위해 안전장치로 설계되어야 한다.
• DKMS는 SSI의 기초가 된 W3C 검증 가능한 자격증명 및 분산 식별자 표준과 같이 모든 오픈 소스 프로젝트 또는 상용 공급업체가 구현할 수 있는 공개 표준을 기반으로 해야한다 이는 Apple iMessage등과 같이 인기 있는 보안 메신저의 접근 방식을 제거한다.
• DKMS는 암호화 알고리즘 및 프로토콜의 진화적 발전을 수용할 수 있어야 한다.
• DKMS는 최종 사용자를 대신하여 전문 지식이나 기술을 가정할 수 없다. 최신 브라우저 및 이메일 클라이언트만큼 사용하기 쉬어야 하며, 무엇보다도 최종 사용자에게 암호화, 블록체인, SSI 또는 공개키/개인키에 개념과 이해를 요구할 수 없다.

자기 주권 신원의 10가지 원칙

1. 존재: 사용자들은 독립적인 존재여야 한다.

   어떤 자기주권신원은 궁극적으로 신원의 중심에 있으면서 형언할 수 없는 ‘나’를 기초로한다. 그것은 결코 완전한 디지털 형태로 존재할 수 없으며 이 것은 유지되고 지원되는 자체 커널이어야 한다. 자기주권신원은 단순하게 이미 존재하는 ‘나’의 제한된 일부의 측면을 공개하고 접근 가능하게 한다.

2. 통제: 사용자들은 자신의 신원을 통제해야 한다.

   신원과 신원의 클레임의 지속적인 유효성을 보장하는 잘 이해되고 안전한 알고리즘에 따라 사용자는 자신의 신원에 대하여 기본적으로 권한이 있다. 사용자는 항상 참조하거나 업데이트하거나 숨길 수 있어야한다. 사용자는 자신이 원하는 대로 가시적이고, 명성이 있으며 개인정보보호 수준을 선택할 수 있어야하며 사용자가 자신의 신원에 대한 모든 클레임을 제어할 수 있다는 것을 의미하지는 않는다. 다른 사용자가 사용자에 대해 클레임을 제기할 수는 있지만 신원 자체에 중심을 두어서는 안 된다.

3. 접근: 사용자는 자신의 데이터에 접근할 수 있어야 한다.

   사용자는 항상 자신의 신원에 있는 모든 클레임 및 데이터를 쉽게 검색할 수 있어야 하며, 자신의 데이터가 가려지거나 숨기는 주체가 없어야 한다. 이것이 사용자가 신원과 돤련된 모든 클레임을 수정할 수 있다는 것을 뜻하지는 않지만, 사용자가 클레임을 알고 있어야 한다는 것을 의미한다. 또한 사용자가 다른 사용자의 데이터에 접근할 수 있는 것이 아니라 자신의 데이터에만 접근할 수 있다는 것을 의미한다.

4. 투명성: 시스템과 알고리즘은 투명해야 한다.

   신원 네트워크를 관리하고 운영하는 데 사용되는 시스템은 신원의 작동 방식, 관리 및 업데이트 방식 모두에서 공개되어야 한다. 알고리즘은 자유롭고 오픈소스이며, 널리 알려져 있으면서, 특정 아키텍처에서 가능한 독립적이여야 하며, 누구나 작동 방식을 검사할 수 있어야 한다.

5. 지속성: 신원은 오래 지속되어야 한다.

   가급적 신원은 영구적 또는 사용자가 원하는 만큼 지속되어야 한다. 개인키를 순환하고 데이터를 변경해야 할 수 있지만 신원은 그대로 유지된다. 빠르게 변화하는 인터넷 세상에서, 이러한 목표는 완전히 합리적이지 않을 수 있으므로, 최소한 신원은 새로운 시원 시스템에 의해 시대에 뒤떨어지기 전까지 지속되어야 한다. 이는 ‘잊혀질 권리’에 위배 되는 것이 아니라, 사용자가 원할 경우 사용자가 신원을 처리할 수 있어야 하며, 클레임은 시간이 지남에 따라 적절히 수정되거나 삭제되어야 한다. 이를 위해서 신원과 신원의 클레임 사이에 확실한 분리가 필요하며 영구적으로 묶여 있을 수 없다.

6. 이식성: 신원에 대한 정보와 서비스는 전송할 수 있어야 한다

   사용자에게 가장 이익이 될 것으로 예상되는 신뢰 가능한 개체인 경우에도 단일한 제 3자가 신원을 보유해서는 안된다. 문제는 그 개체가 사라질 수 있고, 인터넷에서는 대부분 그럴 수 있다는 것이다. 제도는 바뀔 수 있고 사용자는 다른 관할권으로 이동할 수 있기 때문. 전송가능한 신원은 사용자가 어떤 일이 있어도 자신의 신원을 제어할 수 있도록 보장하며 시간이 지남에 따라 신원의 지속성을 향상시킬 수 있다.

7. 상호 운용성: 신원은 가능한 널리 사용할 수 있어야 한다.

   제한된 곳에서만 작동하는 신원은 가치가 거의 없다. 21세기 디지털 신원 시스템의 목표는 신원 정보를 널리 사용 가능하게 하여 사용자의 통제력을 잃지 않고 국제적 신원을 만드는 것이며 지속성과 자율성 덕분에, 이러한 널리 이용 가능한 신원들은 지속적으로 이용할 수 있다.

8. 동의: 신원을 사용함에 동의해야 한다.

   모든 신원 시스템은 신원과 신원의 클레임을 고유하기 위해 구축되며 상호 운용 가능한 시스템은 공유를 확대한다. 그러나 데이터 공유는 사용자의 동의가 있어야만 가능하다. 고용주, 신용정보 기관 또는 친구와 같은 다른 사용자가 클레임을 요청할 수 있지만, 사용자는 클레임이 유효하도록 동의를 해야 한다. 이 동의는 상호작용방식의 동의가 아닐 수 있지만, 신중하고 잘 이해되는 방식이어야 한다.

9. 최소화: 클레임의 공개를 최소화해야 한다.

   데이터가 공개될 때 해당 공개에는 당연한 작업을 수행하는데 필요한 최소한의 데이터가 포함되어야 한다. 예를 들어, 최소한의 연령만 요구하는 경우 정확한 나이를 공개하지 않으면서 연령대만 공개하고 생년월일은 공개하지 않아야 한다. 이 원칙은 선택적 공개, 범위 증명 및 기타 영지식 기술로 뒷받침할 수 있지만, 비상관성은 여전히 매우 어려운 작업이다. 우리가 할 수 있는 최선은 최소화를 사용하여 개인정보보호를 최대한으로 지원하는 것.

10. 보호: 사용자의 권리는 보호되어야 한다.

    신원 네트워크의 요구와 개별 사용자의 권리 사이에 충돌이 있을 때 네트워크는 네트워크의 요구보다 개인의 자유와 권리를 보호하는 측면에서 오류를 범해야 한다. 이를 보장하기 위해 신원 인증은 검열 저항성이 있고, 강제 복원력이 있으며 분산 방식으로 실행되는 독립적인 알고리즘을 통해 수행되어야 한다.

SSI의 원칙

1. 표현 : SSI 생태계는 어떠한 개체(인간적, 법적, 자연적, 물리적 또는 디지털적 실체)라도 디지털 신원을 통해 표현될 수 있도록 수단을 제공해야 한다.
2. 상호 운용성: SSI 생태계는 로열티가 없는 공개 표준을 사용함으로써 각각의 개체를 위한 디지털 신원 데이터가 상호운용적으로 표현, 교환, 보호되도록 해야 한다
3. 분산화: SSI 생태계는 개체의 디지털 신원 데이터를 표현, 통제, 검증하는데 있어 중앙형 시스템이 요구되지 않도록 해야 한다.
4. 통제 및 대리: SSI생태계는 자신의 신원과 관련된 자연적, 인간적, 법적 권리를 가진 개체(신원권리 보유자)가 자신의 디지털 신원을 사용할 수 있는 통제권을 제공하고, 또한 자신이 선택한 대리자 혹은 보호자에게 그 권한을 위임함으로써 이러한 통제권을 행사할 수 있는 권리 역시 제공해야 한다. 이러한 위임의 대상은 개인, 조직, 기기 그리고 소프트웨어를 포함한다.
5. 참여: SSI생태계는 신원 권리 보유자의 참여가 요구되지 않도록 해야 한다.
6. 형평성과 포용: SSI생태계는 신원 권리 보유자가 그 거버넌스 구조 내에서 배제되거나 소외되지 않도록 해야 한다.
7. 사용성, 접근성 및 일관성 : SSI 생태계는 신원 권리 보유자가 에이전트 및 기타 SSI 구성요소에 대한 사용성, 접근성 그리고 사용자 경험의 일관성 측면이 극대화될 수 있도록 해야 한다.
8. 이식성: SSI 생태계는 신원 권리 보유자가 자신의 디지털 신원 데이터 사본을 에이전트나 자신이 선택한 시스템으로 이동 또는 전송할 수 있는 가능성을 제한하지 않아야 한다.
9. 보안: SSI 생태계는 신원 권리 보유자가 안전하게 자신의 디지털 신원 데이터를 보호하고, 자신의 식별자와 암호화 키를 관리할 수 있으며, 모든 상호작용에 대해 종단 간 암호화가 적용될 수 있는 환경을 제공해야 한다.
10. 검증 가능성 및 진위성: SSI 생태계는 신원 권리 보유자가 자신의 디지털 신원 데이터에 대한 진위성을 검증할 수 있는 증거를 제공할 수 있도록 해야 한다.
11. 프라이버시 및 최소한의 공개: SSI 생태계는 신원 권리 보유자가 자신의 디지털 신원 데이터에 대한 프라이버시를 보호할 수 있도록 하고, 특정 상호작용에 대해 요구되는 최소한의 디지털 신원 데이터를 공유할 수 있도록 해야 한다.
12. 투명성: SSI 생태계는 신원 권리 보유자 및 다른 이해 관계자들이 SSI 생태계의 에이전트 및 기타 구성요소가 작동하는 인센티브, 규칙, 정책 및 알고리즘을 이해하는 데 필요한 정보에 쉽게 접근하고 검증할 수 있어야 한다.

이더리움 블록체인 생태계에서의 신원

ERC 725와 ERC 1056은 서로 다른 기능을 하는 자기주권신원에 대한 두 가지 접근 방식이다. ERC 725는 이더리움 계정을 공개된 온체인 신원으로 만드는 데 중점을 두고 있으며, 여기에는 정보를 얼마든지 추가할 수 있다. 이것은 주로 블록체인에 활성화 되고 다른 블록체인의 첨여자들과 성호 작용하기 위한 것이다. 이와 대조적으로 ERC 1056은 모든 신원 정보를 오프체인으로 유지한다. 온체인 스마트 컨트랙트는 해당 신원에 대한 공개 키 레지스트리 역할을 한다. 이더리움에서 작업을 수행하는 다른 방법은 항상 존재하기 때문에 더 많은 방법이 있을 수 있다

Outro

사실 DID에 관련된 지식을 찾기 어려웠는데 책을 읽으며 대략적인 맥락을 잡아가는데 많은 도움이 되었습니다 !

또한 책의 후반부에 Indy-SDK에 대한 실습 코드역시도 Indy SDK에 대한 이해도를 높이는데 많은 도움이 되었습니다!

(많은 에러가 동반했지만...)

SSI에 대해 입문하기 위한 서적으로는 정말 강추드립니다!! ☻☻

Refer. 알렉스 프록샤트 , 드러먼드 리드 저자(글) · 정상효 , 이민호 번역

• 알렉스 프록샤트,드러먼드 리드 , 『마스터링 자기주권 신원』 , 정상효,이민호, 제이펍(2022)

Vitalik Buterin이 2013년에 제안한 BlockChain 시스템이며 Bitcoin을 확장했다고 볼 수 있다. 대표적인 특징으로 EVM(Ethereum Virtual Machine)과 Smart Contract 등이 있다.

Ethereum의 특징

• 한 블록의 평균 크기는 2KB

• EVM을 통해 Smart Contract실행이 가능 ↪Smart Contract는 Turing Complete하다고 표현된다.

• BitCoin은 총 발행량이 2,100만개로 반감기가 있지만 이더리움은 정해진 총 발행량이 없다.

• Bitcoin은 Longest Chain을 선택하는 프로토콜을 사용하지만 Ehereum은 Heaviest Chain을 선택하는 프로토콜을 사용한다. ↪ Bitcoin은 height가 제일 높은 Chain을 선택하지만, Etereum같은 경우는 Subtree가 많은 체인을 선택한다.

• Uncle Block을 채굴한 Miner에게도 어느정도 보상을 제공한다 ↪ _Uncle Block이란 Bitcoin에서 Orphan Block과 메인 네트워크에 영향을 주지 않는다는 점은 비슷하다. _🥲

Account

EOA(Externally owned accounts)

Private Key를 통해 사용하며 새로운 transaction을 생성할 수 있다.

CA(Contract accounts)

Contract Code를 통해 사용하며 CA는 스스로 새로운 transaction을 생성할 수 없다

Account State

• nonce : EOA에서의 nonce는 EOA에서 Tx를 생성할 때 마다 증가하며, CA에서의 nonce는 account에 의해 Contract가 생성될 때 마다 증가한다
• balance : _해당 주소의 소유 Wei의 총 합 _
• storageRoot : Storage trie의 Root Node를 hashing한 값
• codeHash : CA에서의 codeHash는 EVM을 통해 만들어진 hash값이며 EOA에서는 빈 문자열을 hashing한 값이다

Trie

이더리움에서 트리는 Merkle Patricia Trie를 이용하며 모든 block의 header에는 State Trie, Transaction Trie, Recipts Trie의 root값이 존재한다

• State Trie : 위에서 알아본 Account State들이 주로 저장된다. ↪ key값은 account 값이고 value값은 accout의 state로 [nonce, ..., storageRoot]값으로 구성되어 있다.

• Transaction Trie : 각각의 block으로부터 구분되어 있으며 block이 mining된 이후엔 update되지 않는다. ↪ key값은 block내에서 transaction의 index값이며 value값은 nonce, gas price 등으로 구성되어 있다

• Recipts Trie : transaction의 결과에 대해 저장하며 transaction의 영수증과 같은 역할을 한다 _ ↪ _key값은 Transaction Trie와 같이 block내에서 transaction의 index값이며 value값은 gas used, post-trx state 등으로 구성되어 있다

• Storage Trie : Contract상의 유지되는 데이터 등이 저장된다

Fee

Ethereum에서는 transaction의 gas fee와 storage fee를 이용하여 반복문의 무한반복, 네트워크 공격 등에 대한 문제를 대비했다.

Gas & Gas limit

• Gas : Transaction을 실행하기 위한 fee

• Gas Price : Transaction을 위해 사용할 Gas의 단위

• Gas limit : Transaction을 위해 사용할 최대 Gas량을 의미하며 Transaction실행 후 잔액은 반환

• Max transaction fee : Transaction실행을 위해 사용할 Gas와 Gas limit을 곱한 값으로 Transaction실행 후 잔액은 반환

✏️ Max transaction fee 0.001 eth = Gas Price 20gwei × Gas limit 50,000

Storage fee

사용한 Storage 만큼의 fee가 사용되며 최소 32byte에 비례해서 fee가 사용된다.

Contract를 이용해 사용한 storage를 초기화 한다면 일부 gas fee를 반환받을 수 있다. 자세한 내용은 이더리움 황서에서 Appendix G부분에서 확인 가능하다

Transaction & Messages

이더리움에서는 Transaction뿐만 아니라 Internal Transaction(Messages)으로 구분되는 Transaction이 있다

Transaction

Transaction의 구성 요소

• nonce : _sender가 보낸 Transacion의 counting된 수 _

• gas Price : Transaction을 위해 사용할 Gas의 단위

• gas Limit : Transaction을 위해 사용할 최대 Gas량을 의미하며 Transaction실행 후 잔액은 반환

• to : Transaction을 받는 주소

• value : 보내는 Eth, 혹은 Wei의 양 ↪ ✏️ Contract를 생성하는 Transaction에도 사용가능하며 이 경우, Contract의 최초 셋팅 balance이다

• v, r, s : 서명한 sender를 식별할 수 있는 요소

• init : _Contract를 생성하는 Transaction에만 존재하며 최초의 Contract의 셋팅값을 포함해 CA를 초기화하며 이후 byte code를 리턴한다 _

• data : message call에만 존재하는 optional Field이며 parameter등이 들어간다.

🤔 Transaction을 검증 하기 위해서 누가 보낸 Transaction인지를 알아야 하지만 from항목이 없다. 이더리움 Transaction에서는 from 대신 v, r, s라는 요소를 넣어 검증을 하는데 v, r, s는 각각 ECDSA에 의해 생성된 전자 서명 r, s와 어떤 공개키인지를 추측할 수 있는 v로 구성되어 있다. ↪ ECDSA를 검증하는 자세한 과정은 여기에서 찾아보자.

Internal Transaction (Messages)

Internal Transaction은 Contract에 의해 호출된 Transaction을 의미한다

🧐 Internal Transaction에서 연산 등을 위한 gas는 최초의 실행시킨 EOA가 지불한다.

Execution

_ 모든 Transaction 실행 조건_

• RLP 포멧으로 셋팅

• Transaction의 Signature 검증

• Transaction의 nonce와 sender account의 nonce와 같은지 확인

• Transaction의 gas Limit이 기본적으로 사용되는 gas들의 합보다 많은지 확인 ↪Transaction을 실행하기 위해 필요한 기본 21,000gas를 포함해 사용할 Storage fee 등을 계산한다

• sender의 account에 있는 balance가 지불할 금액보다 많은지 확인

𖤐 Transaction의 Storage fee는 4 * X + 68 * Y로 계산한다. ↪ X는 byte code로 변경했을 때 0인 값이고, Y는 0이 아닌 다른 수인 값이다.

𖤐 조건이 확인되면 Transaction은 아래와 같은 순서로 실행된다

** 1. sender의 balance에서 지불할 금액과 Gas를 제한다 **

** 2. sender의 account nonce의 값에 1을 더한다**

** 3. subState을 추척한다 ** ↪ Transaction을 실행시키는 중에 trie에 직접 접근할 수 없으니 trie에서 필요한 데이터를 불러와 임시로 저장하는 subState를 사용한다.

** 4. 필요한 여러가지 연산을 한 후 refund amount를 계산하여 sender에게 반환한다. ** ↪ refund amount는 사용하지 않은 gas(unused gas) + 사용하던 storage 초기화하여 받는 refund(refund of clearing up storage)로 계산한다

** 5. 반환받지 않은 gas는 Miner에게 지급되며 이를 위해 Block에 gas counter에 더한다**

6. Transaction이 종료되며 subState에 있는 지워질 account들은 삭제한다 ↪삭제라는 표현을 사용했지만 실제로 삭제가 아닌 Account State에서 nonce와 balance는 0으로, storageRoot는 NULL값, codeHash는 빈 문자열을 hashing한 값을 넣어 초기화 한다

subState에는 Self-destruct set, Log series, Refund balance가 있다.

• Self-destruct set : Transaction 실행 후 삭제될 amount의 리스트
• Log series : log 리스트
• Refund balance : sender가 반환받을 금액

Block

이더리움의 Block은 BlockHeader, Transaction의 정보, ommer Block의 header 등으로 구성되어 있다

Block Header

Block Header의 구성 요소

• *parentHash * : previous Hsah를 의미하며 이전 블록의 주소값

• uncleHash : 현재 블록의 uncle block 리스트

• beneficiary : Miner의 주소

• *stateRoot * : state trie의 root Node를 hashing한 값

• *transactionRoot * : transaction trie의 root Node를 hashing한 값

• *reciptseRoot * : recipts trie의 root Node를 hashing한 값

• logsBloom : log 정보를 담은 Bloom filter

• difficulty : 해당 블록의 난이도

• number : 현재 블록의 번호

• gasLimit : 블록에 포함된 Transaction들의 총 Gas Limit 값

• gasUsed : 블록에 포함된 Transaction들에서 사용한 총 Gas 값

• timestamp : _현재 블록 생성시간을 Unix timeStamp로 _

• extraData : Block의 여유 공간

• mixHash : 이더리움의 PoW 알고리즘 Ethash의 mixing된 값을 저장

• nonce : 이더리움의 PoW 알고리즘 Ethash에서 사용하는 값

Uncle (Ommer, Stale) Block

fork된 Block으로 메인 네트워크에는 영향을 주지 못하는 Block

• 메인 네트워크에 존재하는 Block은 Stale Block을 Uncle Block으로 제안할 수 있다. ↪Uncle Block을 제안할 수 있는 최대 갯수는 2개이며 검증을 통해 진행되고 Uncle Block으로 확정되면 블록 체굴보상의 1/32를 보상받는다

• Uncle Block을 Mining한 Miner도 보상을 받는다. ↪ Uncle Block Mining Reward = $( (U_n + 8 - B_n) / 8)$ × 기존의 채굴 보상 ↪$U_n$ : Uncle Block의 nonce , $B_n$ : 현재 Block의 nonce

  ✏️ 현재 Block의 nonce와 Uncle Block의 nonce가 같을 경우 기존의 채굴 보상을 받는 것이 이닌 fork로 처리 되어 어떤 체인을 선택하느냐로 나뉘기 때문에 Uncle Block Mining Reward는 없다

EVM & Contact

Contract

solidity를 이용한 어떤 상태를 다른 상태로 변환 시킬수 있는 기능을 포함한 계약을 위한 스크립트 언어로 작성된 프로그램

_Contract 생성시 초기화 _

• nonce는 0으로 설정한다.

• Contract를 생성하는 Transaction에 value값이 있다면 value값을 넣어 balance를 설정하고 sender의 balance에서 제한다.

• storage는 null값을 넣고, codeHash에는 빈 문자열을 hashing한 값을 넣어 설정한다.

📌 최초의 생성시 이더리움 황서에 나와있는 Gas비가 사용되며 사용하는 Storage용량에 비례하여 추가로 더 Gas를 사용한다. 𖤐만약 가스비가 모자른 상황(out-of-gas)이 발생할 경우 상태는 Transaction이 실행되기 전으로 돌아가지만 sender는 Gas를 반환받을 수 없다.

Ethereum Virtual Machine (EVM)

EVM을 통해 모든 Node들은 Contract를 실행할 수 있으며 32bytes 스택기반의 아키텍쳐이다.

특징

• volatile memory : 실행 중에만 사용하는 변수들이 들어가며 stack, arguments, memory를 사용한다

• non-volatile memory : 실행 이후에도 지속되는 변수들이 들어가며 code, storage를 사용한다. ↪ ✓ 실행 이후에도 지속되는 변수는 Storage Trie에 저장되므로 용량의 크기에 따라 Storage fee가 발생한다

Merkle Patricia Trie란 이더리움에서 사용하는 자료구조이며 Merkle trie를 변형해서 사용한다

특징

• _각각의 노드는 sha3을 이용해서 hashing 한다 _

• _MPT는 key-value DB이다 _ ↪ level DB은 Go, C++, Python client에서 사용되고, rocks DB은 Parity client에서 사용된다. _ ↪ _key는 각 Node의 hash이고 value는 각 Node의 값을 의미한다.

• _Merkle Tree처럼 하나의 Node라도 변경될 경우 Root Hash에 영향을 주게 되어 값의 안전성을 보장할 수 있다 _

타입

• NULL : NULL은 빈 문자열값을 의미 한다.

• branch : 1617개의 요소로 구성되어 있는 배열이다 015번 Index는 hashing된 주소값이 들어갈 수 있으며 value가 있는경우에는 마지막 index로 value의 값이 들어간다. ↪ hashing된 주소값은 index에 맞춰 들어간다

• leaf : 2개의 요소로 구성되어 있는 배열이며 encodedPath와 value값이 들어가 있다.

• extension : 2개의 요소로 구성되어 있는 배열이며 encodedPath와 key값이 들어가 있다.

hex Prefix Encoding

_extension Node 와 leaf Node를 구별하기 위해 사용 _ ↪Merkle Patricia Trie는 nibble 단위로 저장된다, nibble은 4bit 즉 0.5byte이며 hex char역시도 4bit이며 1byte로 떨어지지 않을 경우 1byte를 맞추기 위해 0을 이용하여 padding한다.

📌 Example

가상의 path 예시

• <64 6f> : "Kevin"
• <64 6f 67> : "FOEN"
• <64 6f 67 65> : "David"
• <68 6f 72 73 65> : "YAYA"

가상의 key - value을 기준 trie 예시 rootHash : [ <16>, hashA ] hashA : [<>, <>, <>, <>, hashB, <>, <>, <>, hashC, <>, <>, <>, <>, <>, <>, <>, <>] hashB : [<00 6f>, hashD ] hashC : [<20 6f 72 73 65>, "YAYA"] hashD : [<>, <>, <>, <>, <>, <>, hashE, <>, <>, <>, <>, <>, <>, <>, <>, <>, "Kevin"] hashE : [<17>, hashF] hashF : [<>, <>, <>, <>, <>, <>, hashG, <>, <>, <>, <>, <>, <>, <>, <>, <>, "FODEN"] hashG : [<35>, "David"]

✏️ Example hash 특징

__ hashA__ : branch Node이며 value가 존재지 않기 때문에 16개의 hashing된 주소값이 들어갈 수 있는 index로만 이루어져 있다 hashB, hashE : extension Node이므로 encodedPath와 key로만 이루어져 있다 hashC, hashG : leaf Node이므로 encodedPath와 value로만 이루어져 있다 hashD, hashF : branch Node이며 value가 존재하므로 16개의 hashing된 주소값이 들어갈 수 있는 index와 value로 이루어져 있다.

Satishi Nakamoto가 2009년 발표한 대표적인 Public BlockChain 시스템

🪙 Bitcoin의 특징

• ECDSA 기반의 전자 서명 알고리즘 이용

• 9000개 이상의 Full Node로 구성된 네트워크 보유

• 평균 10분마다 새로운 블록을 채굴 ↪PoW 난이도 조절을 통해 채굴 속도를 조절하며 이를 통해 stale block의 양을 줄이며, 51% Attack도 방지할 수 있다

• 통화 발행을 2,100만개로 제한 ↪인플레이션 방지를 위함으로 추측하며 그 이후의 채굴자에게는 Tx Fee가 수수료로 돌아간다

• 한 블록의 평균 크기는 1.29Mbyte ↪한 블록당 약 2000개의 트랜잭션이 포함된다

🔑 Key

타원 곡선(Secp256k1)을 이용해 개인 키, 공개 키 사용

• 타원 곡선 : $Y^2 = (X^3 + 7) mod p$

• Private Key ($k$) : $1$ ~ $2^{256}$ 사이의 랜덤한 숫자

• Public Key ($K$) : $k * G$ ↪ $G$ : 타원 곡선 상의 고정된 점 ↪ $*$ : 타원 곡선 상의 곱하기 연산

🖊이 부분은 이전게시글의 ECDSA부분을 참고하면 된다.

주소

위에서 본 Public Key는 520bi, 즉 65Byte의 크기를 갖게 되는데 이럴 경우 블록에 담기에는 너무 큰 크기를 갖기 때문에 암호 해시를 이용해서 생성한다

📌 Public Key $K$의 구조는 prefix 8bit, x좌표 256bit, y좌표 256bit로 총 520bit가 된다

Public Key를 이용하여 주소로 변환하는 과정

출처 : oreilly

Base58Check Encode

Base58Check Encode 과정

출처 : oreilly

• Base-58 ↪숫자와 알파벳 중 햇갈릴 수 있는 0, O, I, l 네 개의 문자들을 제거한 58가지 문자로 인코딩하는 방법

• Prefix ↪8bit이며 주소의 버전을 의미하며 자세한 목록들은 [여기서] (https://en.bitcoin.it/wiki/List_of_address_prefixes) 확인 가능하다

• Checksum ↪에러를 체크할 수 있는 해싱된 코드이며 Payload 뒤에 붙여준다.

BSL

Bitcoin Script Language의 약자로 대표적인 특징으로 튜링 불완전성언어로 반복문의 기능이 없다는 점과 Stack기반의 프로그래밍언어로, 입력이 맞으면 TRUE, 그렇지 않으면 FALSE를 저장한다

📌 BSL에 관한 자세한 정보는 위키피디아에서 확인 가능하다

Transaction

비트코인에서의 트랜잭션은 화폐의 흐름을 표기

{
  "version": 1,
  "locktime": 0, 
  "vin": [{
    "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
    "vout": 0,
    "scriptSig" : "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039 ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787e c3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
    "sequence": 4294967295 }],
  "vout": [{
    "value": 0.01500000,
    "scriptPubKey": "OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG"
  },
  {
    "value": 0.08450000,
    "scriptPubKey": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG",
  }] 
}

• Input : 트랜잭션 id와 포함한 Signature, Locking Script(scriptPubKey) 등이 포함되어 있다

• Output : 트랜잭션 결과로 가져갈 금액과 Unlocking Scrript(scriptSig)가 포함되어 있다

• Tx fee : _트랜잭션을 포함한 블록을 채굴할 마이너에게 지급되는 fee로 _입력금액 - 출력금액_으로 계산된다 _

Tx Verification

각 Node들은 이웃 Node들에게 전파하기 전, 유효성을 검증한 후 전파한다

📌 _각 Node들이 Tx를 검증하기 위한 자세한 CheckList는 여기서 Independent Verification of Transactions 항목을 통해 확인 가능하다. _

UTXO

*Unspent Transaction Outputs의 약자로 미사용 트랜잭션 출력 값을 의미한다 따라서 사용자의 총 잔고는 UTXO의 총합을 의미한다고 볼 수 있다. *

예시를 들자면 A와 B가 나에게 각각 2,000원을 보내주었다고 했을 때 나의 잔고는 4,000원이 아닌 2,000원 두개가 된다. 다시 내가 C에게 3,000원을 보낼 경우 2,000원 두 개를 트랜잭션에 등록하여, 3,000원은 C에게, 1,000원은 나의 잔고로 등록이 된다. 트랜잭션이 등록되고 블록에 올라가기 전에는 Mempool에 등록되며 이를 통해 비트코인은 이중지불에 대한 방지를 할 수 있으며 거래에 대한 유효성을 검증하는데 사용된다.

Coinbase Transaction

블록을 채굴한 Miner에게 보상으로 지급되는 Transaction

📌 _Miner에게 돌아가는 채굴의 보상은 기존의 UTXO의 거래 수수료와 Coinbase Tx의 합으로 가져가가며, 비트코인의 총 발행량인 2,100만개 이후에는 Coinbase Tx는 없이 순수 거래 수수료만 채굴 보상으로 받을 수 있다. _

Bitcoin Node

노드들은 대표적으로 네 가지 역할을 갖고 있다

• Routing : 트랜잭션과 블록을 검증 및 전파하며 다른 Peer와 연결을 유지

• BlockChainDB : 블록체인의 전체 혹은 헤더를 저장

• Mining : 새로운 블록을 추가 및 PoW알고리즘 수행

• Wallet : 사용자의 화폐, 주소, 키 관리 및 트랜잭션 생성

노드들은 크게 4가지로 분류할 수 있다.

• Full Node : Routing, BlockChainDB, Mining, Wallet기능을 모두 갖고 있는 노드

• SPV Node : Simplified Payment Verification Node로 Routing, Wallet 기능을 갖고 있다

• Solo Miner : Routing, BlockChainDB, Mining 기능을 갖고 있으며 채굴을 주 목적으로 하는 Node

• Mining Node : Pool protocol server에 의해 관리되는 Mining기능만 갖고 있는 Node

SPV Node 와 Full Node 상호작용 단계

1. 특정 SPV Node A가 다른 SPV Node B에게 보내는 Trancsaction을 생성 후 네트워크에 전파
2. Transaction이 B에게 전다르 되면 정상적으로 전파된 것으로 확인가능하며 Transaction은 Pool에 저장된다
3. A가 B에게 보내는 Transaction이 포함된 블록을 후보 블록으로 생성한 Miner가 채굴에 성공할 경우 네트워크에 전파
4. 다른 Full Node들도 블록을 검증하고 SPV Node B는 다른 Full Node에게 블록 헤더를 수신 ↪SPV Node B가 Full Node에게 자신의 Transaction이 포함 되었는지를 확인하기 위해 특정 Transaction만을 요청하면 Full Node는 SPV Node B를 특정할 수 도 있다. 이 때 Bloom Filter를 이용한다

Bitcoin Block

nonce, Target, Difficulty

• nonce : 비트코인 PoW의 정답을 의미하며 nonce를 찾은 Miner가 Coinbase를 포함한 Tx Fee를 받아간다. Miner들이 nonce를 찾는 것은 어렵지만 주변 다른 Node들이 nonce를 검증하는 것은 쉽다는 특징이 있다

• Target : 비트코인 PoW의 문제를 의미하며 Miner는 Target보다 작은 해시값을 찾아야 한다.

• Difficulty : 비트코인 PoW Target의 난이도를 의미한다. 블록은 평균 10분에 1개가 채굴됙게 되는데 2,016개의 블록마다 채굴 평균속도가 길경우, Difficulty가 내려가고, 빠를경우 Difficulty가 올라간다

Block Verfication

Miner가 nonce를 찾더라도 바로 블록에 올라가는 것이 아닌 nonce를 찾은 Miner가 제안하는 블록을 검증 후 주변 노드들에게 전파한다

📌 각 Node들이 Block을 검증하기 위한 자세한 CheckList는 여기서 Validating a New Block 항목을 통해 확인 가능하다.

Orphan Block

채택되지 못한 Block을 의미하며 고아 블록이라고도 한다

만약 같은 height의 Block을 동시에 찾았다면 그것을 전파받은 Node들은 각자 검증 후 그 이후의 height의 Block을 채굴하며 최종적으로 제일 height가 높은 블록을 모두에게 전파한다. 이 과정에서 모두에게 전파되지 못한 블록들을 Orphan Block이라고 하며 이런 시스템 때문에 Block이 Chain에 올라가더라도 최종적으로 승인이 되기 위해선 6개의 Block이 올라가야 거래가 확정되며 Coinbase Tx도 100개의 Blcok 이후에 승인된다.

특정 집합에 포함되지 않은 데이터를 구분하기 용이한 자료구조

• N bit 배열과 M개의 해시 함수로 구성되어 있다.

• 특정 패턴을 사용한 해시 함수를 이용하여 배열중 하나를 가르키게 되는데, 이 때 모두 1을 가르키는 경우 있을 가능성이 있는 것이고, 한 개라도 0을 가르키면 확실하게 존재하지 않는 것이다.

✓ N = 18, M = 3인 Bloom Filter

Merkle tree

트랜잭션이 저장된 블록의 무결성을 보장하기 위해 사용하는 자료구조

• _Binary Hash Tree구조를 갖고 있으며 계산이 단순하고 빠르다는 장점을 갖고 있다 _

• Merkle Path를 이용해 트랜잭션이 블록에 포함되어 있는지를 쉽게 파악 가능하다

• 리프노드들을 concatenate operator를 통해 단순 더한 후 해싱하여 루트노드를 생성한다 ↪ 🖋 트랜잭션 수가 홀수일 경우에는 마지막 트랜잭션의 해시값을 중복으로 계산한다

✓ Merkle tree

전자 문서의 데이터 무결성과 출처 증명을 위한 암호화 알고리즘

전자 서명 & 일반 서명

전자서명 특징

• Message Authentication (인증) ↪발신자의 공개키를 통해 검증되므로 발신자가 보낸 것을 인증가능 하다
• Message Integrity (무결성) ↪ _ 메세지가 수정될 경우 서명이 변경되기 때문에 무결성이 검증된다_
• Nonrepudiation (부인 방지) ↪ 신뢰가능한 제 3자를 있다면 발신자가 보낸 메세지를 발신자가 보내지 않았다고 주장하기 어렵다

𖤐_전자서명은 기밀성유지를 위해 사용되지 않는다. _ ↪ Plain Text를 이용하여 서명할 경우에는 검증과정에서 PlainText가 그대로 노출 될 수도 있다. 이와 같은 이유와 비대칭 키 암호화의 특징을 고려해 PlainText를 해싱하여 Digest로 만든 후 서명한다

RSA 디지털 서명

키 생성방법 🔑

🖋 키 생성방법은 전에 정리한RSA의 키 생성방법과 동일하다! 😏

검증 🧐

_ 검증부분 역시 RSA 검증 부분과 비슷하다 _ 🥲 $S$ : Signature $M$ : Message

• $S = M^d mod n$
• $S^e = (M^e mod n)^d = M^{ed} mod n$
• $ed = k × φ⒩ + 1$
• $S^e = M^{ed} mod n= M^{k × φ⒩ + 1} mod n$
• $S^e = M^{k × φ⒩ + 1} mod n = M mod n$ ⤷ 𖤐 φ⒩ 오일러의 정리 마지막 부분 😉

ECDSA (타원곡선 디지털 서명 구조)

키 생성 방법 🔑

1. 타원 곡선 $E_p (a,b)$ 를 선택 ⤷📌 $p$는 prime Number,소수이다 ⤷ $Y^2 mod p = (x^3 + ax + b) mod p$
2. 다른 소수 $q$와 개인 키로 사용할 정수 $d$ 선택
3. 타원 곡선 상 한 점 $e_1$를 선택한다 ⤷이 점을 generator라고도 한다
4. 선택한 $e_1$와 개인 키로 사용하는 정수 $d$를 이용해 다른 한 점 $e_2$를 계산 한다 ⤷$e_2(... , ...) = d×e_1(... , ...)$
5. 개인키는 선택한 정수 $d$가 되고, 공개키는 $e_2$가 된다 ⤷ 그러나 공개된 값이 $a, b, p, q, e_1, e_2$이기 때문에 모두 공개키라고 볼 수도 있다

검증 🧐

Sign

Temporary Private Key : $r$ ⤷ 1 < $r$ < $q$ -1 Temporary Public Key : $P(u,v) = r×e_1(... , ...)$

• $S_1$ : $u mod q$
• $S_2$ : $(h(M) + d×S_1) × r^{-1} mod q$ ⤷ ∴ Signature : ($S_1$, $S_2$)

Verify

1. 먼저 아래와 같이 가정한다 $A$ = $h(M)×S_2^{-1} mod q$ $B$ = $S_1×S_2^{-1} mod q$
2. Sign할 때 $S_2$를 만든 알고리즘을 통해 $r$의 값을 구한다 $S_2$ : $(h(M) + d×S_1) × r^{-1} mod q$ ⤷ ✏️ $r$ : $(h(M) + d×S_1) × S_2^{-1} mod q$
3. Public Key를 이용하여 식을 간소화 ⤷ $P(u,v) = r×e_1 = (h(M) + d × S_1) × S_2^{-1} mod q$ = $(h(M)× S_2^{-1}) + (d × S_1× S_2^{-1}) mod q$ = $A× e_1 + d × B × e_1 mod q$ = $A× e_1 + B × e_2 mod q$
4. 타원 곡선 상 점 $T$의 좌표를 생성 ⤷$T(x, y)$ = $A × e_1 + B × e_2$
5. $S_1 = u mod q$ 이므로 $S_1 = x mod q$ 일 경우 검증 완료 📝

유한체상의 타원곡선 이론에 기반한 공개키 암호

타원 곡선 암호 시스템의 특징

• RSA의 키는 보통 1024bits 이상이지만 ECC는 256bit 이상의 크기를 갖으며 상대적으로 짧은 키의 길이로 같은 보안 수준을 제공할 수 있다.

• 실수 상의 타원곡선

  • 모든 근이 실근일 경우, 좌표의 수평선과 곡선이 3점에서 교차한다

$y^2 = x^3 + ax + b$ _그래프 _ ⬇

타원 곡선 상의 덧셈 연산

타원곡선 상에서 두 점($P$,$Q$)을 정한 후 두 점을 지나가는 직선이 타원 곡선과 만나는 3번째 교점을 $x$축 기준으로 대칭되는 점을 $R$로 정의하여 계산하는 것을 기초한다

$P$ = ($x_1$, $y_1$) , Q = ($x_2$, $y_2$) $R$ = $P + Q$

🖋 $R$ = ($x_3$, $y_3$) 계산 방법

$a$ . $P ≠ Q$

$m$(기울기) = $(y_2 - y_1) / (x_2 - x_1)$ $x_3 = m^2 - x_1 - x_2$ $y_3 = m(x_1 - x_3) - y_1$

$b$ . $P = Q$

$m$(기울기) = $(3x_1^2 + a) / (2y_1)$ $x_3 = m^2 - x_1 - x_2$ $y_3 = m(x_1 - x_3) - y_1$

GF($p$)상의 타원 곡선

GF는 Galois Field, 유한체를 의미하며 $p$는 Prime Number 즉 소수를 의미한다

* Modulo $p$를 이용한 타원곡선 특징*

• $x$의 값은 0~ $p$-1 사이에 존재한다.

• 덧셈연산은 덧셈 결과를 mod $p$연산 해준다.

• 역원은 $(x,y)$ 기준 $(x, -y)$이며 여기서 $-y$는 $y$의 덧셈에 대한 역원이다 ↪_$p$가 13일때 $(1,4)$의 역원은 $(1,-4)$이며 즉 $(1,9)$이다 _

Hashing(해싱)은 해싱된 값을 통하여 데이터의 무결성을 증명할 수 있는 수단이다

암호 해싱 함수

입력 문서를 고정된 길이의 데이터로 변환하며 역으로 고정된 길이로는 입력 문서를 찾을 수 없는 단방향 속성을 갖고 있다.

종류

• MD5 : 1991년 만들어진 128비트 알고리즘 ⤷충돌 저항성 ⬇

• SHA-1 : 1995년 미국의 NIST에서 만들어진 160비트 알고리즘 ⤷충돌 저항성 ⬇

• SHA-2 : 2002년 미국 NIST에서 만들어진 알고리즘이며 해시 값의 크기에 따라 나뉜다 ⤷SHA-256 , SHA-384 , SHA-512등이 있으며 SHA-256은 BitCoin에서도 사용된다

  • SHA-3 : 2012년 미국 NIST에서 선정되었다. ⤷_SHA3-224 , SHA3-256 , SHA3-384 , SHA3-512등이 있으며
  • Ehtereum에서 사용하는 Keccak-256의 기반이 되었다*_

𖤐 암호 해시 함수의 조건

$M$ : Message , $H()$ : Hash function, $H(M)$ : Digest

• Preimage resistance (단방향성) $y = H(M)$일 경우 공격자가 $y$와 $H()$를 이용하여 $M$을 발견하는 것은 어려워야 한다
• Second Preimage resistance (약한 충돌 저항성) $M$과 $H(M)$이 주어졌을 때 $M'$ ≠ $M$ 이면서 $H(M')$ = $H(M)$인 $M'$를 찾기 어려워야 한다 ⤷Message와 해싱된 값이 주어졌을 경우, 해싱된 값이 같으면서 다른 Message를 찾긱 어려워야 한다
• Collision resistnace (충돌 저항성) $H(M)$ == $H(M')$인 서로 다른 메세지 $M$과 $M'$를 찾기 어려워야 한다 ⤷a가 해싱된 값이 0일 경우와 b가 해싱된 값이 0일 경우 b를 찾기 어려워야 한다

상용 암호 해시 알고리즘

Iterative Hashing

1. 메시지를 $n$비트 크기의 블록으로 분할하며 마지막 블록에 메세지의 길이 블록을 추가한다
2. 메시지를 분할한 블록의 수 만큼 해싱한다 ⤷*i단계에서는 *$H_{i-1}$ , $M_i$*의 값을 받아 Hashing하여 $H_i$를 생성한다 *
   3. 최종 생성되는 Digest 값이 최종 해싱된 값($H$)이 된다

MDC (Modification Detection Code)

변경 감지 코드라고 하며 해당 메시지가 변경되지 않았다는 것을 보장하기 위해 사용한다

⤷무결성은 증명가능하지만 송신자를 인증 불가능하다는 단점이 있다

🖊 Message를 해싱한 MDC와 Message를 보내서 검증한다

• MAC (Message Authentication Code)

송신자와 수신자 사이에 대칭 Key를 이용해 MDC를 검증한다

⤷송신자 인증까지는 가능하지만 Key가 노출될 위험이 있을 수 있다.

🖊 송신자는 Message와 Key를 이용해 해싱한 MDC와 Message를 보내며 수신자는 자신이 갖고 있는 Key를 이용해 Message와 해싱하여 받은 DMC와 수신자 본인이 해싱한 DMC가 같은 지를 검증하여 무결성과 송신자가 맞는지를 증명한다

• HMAC (Hased Message Authentication Code)

  NIST에서 사용하는 표준 MAC이다

🖊 송신자는 Message, Key, ipad를 이용해 해싱한 값을 다시한번 key와 opad를 이용해 해싱한 HMDC와 Message를 수신자에게 보내며 수신자는 동일한 방법으로 검증한다

가장 널리 쓰는 공개 키 알고리즘 중 하나로 전자서명이 가능한 최초의 공개 키 알고리즘으로 알려져 있다.

개념

• **Public Key : e, n ** ⤷ Plain Text의 크기는 n을 넘을 수 없으며 n은 1024 bits 이상의 수 이다

• * Private Key* : d
• $C = P^e mod n$
• $P = C^d mod n$

생성 알고리즘

*1. 512비트 이상의 큰 소수 p, q를 선택 * ⤷ p ≠ q _ 2. *n = p × q * ⤷ _n은 1024비트 이상의 수가 된다 3. ** φ⒩ = ( p - 1) × ( q - 1 ) ** 4. ** φ⒩ 와 서로소인 e를 선택 ⇒ _ 1 < e < φ⒩ _ **

• Public Key : e, n
• *Private Key : d = e⁻¹ mod φ⒩ * ⤷확장 유클리드 알고리즘 사용

RSA 정확성 증명과 예시

• 전송한 PlainText($P$)가 전송받은 CipherText($C$)를 복호화 한 PlainText($P_1$)과 같다는 걸 증명

• $P^1 = C^d  mod n = (P^e mod n)^d = P^{ed} mod n$

• $ed = k × φ⒩ + 1$
• $P^1 = P^{ed} mod n= P^{k × φ⒩ + 1} mod n$
• $P^1 = P^{k × φ⒩ + 1} mod n = P mod n$ ⤷ 𖤐 φ⒩ 오일러의 정리 마지막 부분 참고!

Euclidean algorithm (유클리드 알고리즘)

두 수를 받아 나머지연산을 하여 최대 공약수를 구하는 알고리즘으로 golang을 이용하여 구현하면 다음과 같다

func main() {
    var a, b int
    reader := bufio.NewReader(os.Stdin)
    fmt.Fscanf(reader, "%d %d", &a, &b)  // a,b를 입력 받는다
    if a < b {
        a, b = b, a // 나머지 연산을 하기 위해 b가 a보다 클 경우 자리를 바꿔준다
    }
    gcd := 0  // 최대공약수 선언
    for {
        r := a % b 
        if r == 0 {
            //나머지 연산 값이 0일 경우 최대 공약수 값은 0이 되며 반복문은 종료
            gcd = b
            break
        }
        // 나머지 연산 값이 0이 아닐 경우  a에는 b를, b에는 나머지 연산 값을 선언해서 반복 
        a = b
        b = r
    }
    fmt.Println(gcd)
}

𖤐 Extended Euclidean algorithm (확장 유클리드 알고리즘)

• RSA에서 Private Key를 구하기 위해 사용한다.

  func main() {
    var a, b int
    reader := bufio.NewReader(os.Stdin)
    fmt.Fscanf(reader, "%d %d", &a, &b)
    r1 := a
    r2 := b
    t1 := 0
    t2 := 1
    for r2 > 0 {
        q := r1 / r2
        r := r1 - q*r2
        r1, r2 = r2, r
        t := t1 - q*t2
        t1, t2 = t2, t
        r = a % b
        if r1 != 1 {
            // if r1 != 1일 경우 a, b가 최대공약수가 1이 아니므로, b의 inverse는 존재하지 않는다
            fmt.Println(0)
        }
        if t1 < 0 {
            // 만약 t1이 음수가 되면 "t1 % n" 또는 t1을 더해주어서 해결한다
            t1 = a + t1
        }
    }
    fmt.Println(t1)
  }

암호화와 복호화

• Encryption (암호화) : PlainText(P)와 공개키 e, n을이용해 $P^e mod n$을 계산

  RSA_Encryption (P, e, n) {
    C = Fast_Exponentiation(P, e, n)
    retrun C
  }

• Decryption (복호화) : CipherText(C)와 비공개키 d, n을이용해 $C^d mod n$을 계산

  RSA_Decryption (C, d, n) {
    P = Fast_Exponentiation(C, d, n)
    retrun P
  }

Fast_Exponentiation

$y= a^x mod n$을 계산하며 계산 시간을 단축하기 위해 Square and Multiply 개념을 이용해서 계산

$y= a^9 = a^{1001_2} = a^8 × 1 × 1 × a$

위와 같은 식을 golang의 rsa 패키지를 이용하여 구현할 수 있고, 패키지 안의 코드는 아래와 같다

func SquareAndMultiply(base int, exp int, modulo int) int {
    res := base
    // converst the number to a string of 0 and 1 in binary
    bin := strconv.FormatInt(int64(exp), 2)
    for e := 1; e < len(bin); e++ {
        res *= res
        res %= modulo
        if bin[e] == '1' {
            res *= base
            res %= modulo
        }
    }
    return res
}

비밀 키와 공개 키를 한 쌍으로 암호 키로 사용하여 암호화

활용 메커니즘

• 비밀 메시지 : A의 공개키로 암호화한 암호는 A의 비밀 키로 복호화
• 전자 서명 : A의 비밀 키로 암호화한 암호는 A가 암호화 했다고 증명 가능

𖤐 대칭 키 암호와 비대칭 키 암호의 차이

One-Way Function

단 방향 함수라고도 하며 가장 대표적인 예시로 해시함수가 있다.

• x가 주어질 경우 f(x)의 계산은 쉽지만, y가 주어지더라도 f⁻¹(y)를 통해 x를 계산하는건 어렵다

y = xᵏ mod n 만약 n>x이고 x와 k가 주어진다면 계산이 쉽다. 그러나 y, n, k을 이용하여 _x_를 계산하는 것은 어렵다.

Trapdoor

단 방향 함수이며 힌트가 주어지면 f⁻¹(y)를 이용해 x를 구할 수 있다

k * k' = 1 mod n이고, k를 알 수 있다면 x = yᵏ mod n을 이용해 x를 구할 수 있다 ↪ k :_ 공개 키, k' : 비공개 키_

Euler 의 φ⒩

Z_n* *에 속하고 *n보다 작으면서 n과 서로소인 정수의 개수

🖊 φ⒩ 특징

• φ(1) = 0

• p가 소수일 경우 ⮕  φ(p) = p-1
• p가 소수일 경우 ⮕  φ(pᵉ) = pᵉ - pᵉ⁻¹
• m과 n이 서로수일 경우   ⮕ φ(m * n) = φ(m) * φ(n)

🖊 φ⒩ 오일러의 정리

• a과 n이 서로수일 경우   ⮕ $a^{φ(n)} = 1  mod  n$

• a < n이고 k가 정수일 경우   ⮕ $a^{k × φ(n)+1} = a  mod  n$

암호화와 복호화를 하기 위해 사용되는 키가 동일한 경우

𖤐 대칭키 알고리즘

평문 (P) : PlainText, 암호문 (C) : CipherText , 키 (K) : Key, 암호화 알고리즘 (E) : Encryption Algorithm , 복호화 알고리즘 (D) : Decryption Algorithm

• C = E⒦( P )
• P = D⒦( C )
• 송신자 : E⒦( P )
• 수신자 : D⒦( C ) = D⒦( E⒦ ( P ) ) = P

𖤐 Kerckhoff의 원리

암호화에서 암호화 알고리즘의 안전성보다 키의 안전성이 더 중요하다

• 공격자는 항상 암호화 알고리즘 ( E )와 복호화 알고리즘( D )은 알고리즘은 알고있다고 가정해야한다
• 그러므로 안전성은 키의 안전성에 바탕을 둔다

암호 해독 공격

• Brute-Force Attack (전수조사 공격) : 암호문을 가로챈 후 모든 가능한 키를 사용하여 복호화 한 후 평문 획득
• Statistical Attack (통계적인 공격) : 평문언어의 고유한 특징들 을 이용하여 복호화한다 예를 들어 영어에서 제일 빈번하게 나오는 단어는 E이며 암호문 역시 가장 빈번하게 나오는 단어를 E라고 가정하고 복호화 한다
• Pattern Attack (패턴 공격) : 암호문에서 존재하는 패턴을 연구해 복호화

대치 암호

어떠한 기호를 다른 기호로 대체하는 암호종류

• Monoalphabetic ciphers (단일문자 암호) : 평문의 기호와 대응하는 암호문 기호는 항상 1:1 대응관계
• Polyalphabetic ciphers (다중문자 암호) : 평문의 기호와 대응하는 암호문 기호는 1:M 대응관계

📍 단일 문자 암호

Additive Cipher (덧셈 암호)

가장 기본적인 암호이며 알파벳을 기준으로 평문과 암호문의 키는 Z26의 원소가 된다

C(암호문) = (P + k) mod 26 P(평문) = (C - k) mod 26

Multiplicative Cipher (곱셈 암호)

키는 평문과 암호문이 해당하는 Z26의 원소에서 역원이 존재하는 원소

C(암호문) = ( P * k ) mod 26 P(평문) = (C * k^-1) mod 26

Affine Cipher (아핀 암호)

덧셈 암호와 곱셈 암호를 결합하여 두개의 키를 사용한 암호

📍 다중 문자 암호

Autokey Cipher (자동키 암호)

첫 번째 키를 미리 정의한 후 나머지 키는 평문의 문자를 이용해서 암호화하는 방식

Playfair Cipher (플레이페어 암호)

1차 세계대전에서 영국군이 사용한 암호 방식이며 5 * 5 행렬로 배열된 알파벳 문자로 이루어진 비밀키를 기준으로 규칙을 정해

전치 암호

기호를 다른 기호로 변경하는 것이 아닌 재 정렬시켜 암호화하는 방식

📍 Keyless Transpostion ciphers (키가 없는 전치 암호)

Rail fence 암호

평문을 합의한 열의 개수를 기준으로 단어를 재조합하는 방법

• ☼ 열 2개로 암호화 Hello World => HLOOL , ELLWRD

📍 Keyed Transpostion ciphers (키가 있는 전치 암호)

사전에 합의된 크기로 평문을 블록 단위로 나눈 뒤 각각의 블록에 키를 대입하여 재배치하는 방법

• ☼ 2개로 암호화

• 2	1
  1	2

• Hello World => EH,LL, WO , RO, DL

𖤐 AES (Advanced Encryption Standard)

2001년 NIST(미국 국립기술 표준원)에서 공표한 대칭키 암호 알고리즘이며 높은 안정성과 속도로 전 세계적으로 많이 이용하고 있으며 암호화 키의 길이에 따라 AES-128, AES-192, AES-256로 나뉜다

보안을 위해 보통 세 가지 목표를 잡는다고 한다 이 세 가지 요소의 앞 글자를 따서 CIA라고 이야기하기도 한다

1. 기밀성 (Confidentality) : 인가된 사람들만 정보를 조회 및 접근할 수 있다

   𐃉 위협하는 공격 : Snooping, 트래픽 분석 등 외부에서 비인가 데이터에 접근 혹은 탈취하는 공격들

2. 무결성 (Integrity) : 정보들은 무단으로 상태가 변경되지 않도록 한다 𐃉 위협하는 공격 : Spoofing 등 다른 사람으로 위장하여 정보를 조작하거나 탈취 후 다른 시점에 재사용하는 공격들

3. 가용성 (Availability) : 인가된 사람들이 정보를 이용함에 문제가 없어야 한다 𐃉 위협하는 공격 : DoS(Denial of Service) 종류의 서비스를 느리게 하거나 완전히 차단할 수 있는 공격들

Modular Arithmetic(모듈러 연산)

모듈러 연산이란 정수와 정수를 나눗셈 연산을 하여 나온 나머지를 계산하는 연산이라고 볼 수 있다

표기법

9를 2로 나누었을때 나머지

9 % 2

X = 9 mod 2

특성

• a ≡ b mod n = b ≡ a mod n
• a ≡ b mod n && b ≡ c mod n => a = c
• (a + b) mod n = ((a mod n) + (b mod n)) mod n
• (a - b) mod n = ((a mod n) - (b mod n)) mod n
• (a * b) mod n = ((a mod n) * (b mod n)) mod n

Equivalence Classes

같은 수로 모듈러 계산을 할 때 나오는 값이 같으면 동치류라고도 하며 이 동치류 원소들은 해당 모듈러 연산 기준으로는 동일한 값으로 취급된다

예시 1 ≡ 3 mod 2 1 ≡ 5 mod 2 1 ≡ 19 mod 2 1 ≡ 231123 mod 2

위처럼 3, 5, 19, 231123은 mod 2 안에서는 같은 값으로 취급된다.

Identity & Inverse

Identity (항등원) : 어떤 수에 어떠한 연산을 했을 때 처음과 동일한 수가 나오는 수

• 덧셈에 대한 항등원 : 0

  a + 0 = a x + 0 = x

• 곱셈에 대한 항등원 : 1

  a * 1 = a x * 1 = x

Inverse (역원) : 어떤 수에 어떠한 연산을 했을 때 항등원이 나오는 수

• 덧셈에 대한 역원

  a + -a = 0 x + -x = 0

• 곱셈에 대한 역원

  a * a^-1 = 1 x * x^-1 = 1

Mondular 연산에서 항등원과 등원

• 덧셈에 대한 항등원

  (a + 0) mod n = a mod n (x + 0) mod n = x mod n

• 곱셈에 대한 항등원

  (a * 1) mod n = a mod n (x * 1) mod n = x mod n

• 덧셈에 대한 역원

  (a + -a) mod n = 0 mod n (x + -x) mod n = 0 mod n

• 곱셈에 대한 역원 모듈러 연산은 정수를 사용하므로 *a = x mod n 에서 a와 n의 최대공약수가 1인 경우에만 역원이 존재하고, 그렇지 않은 경우에는 역원이 존재하지 않는다.*

  ( 1 * x ) mod 3 = 1 ⇨ x = 1 ( 2 * x ) mod 3 = 1 ⇨ x = 2 ( 3 * x ) mod 3 = 1 ⇨ x는 존재하지 않는다

참고 : https://www.youtube.com/watch?v=MAd3IJEaMls