LabHub
学习 学习路径 课程

闭网现场 — 国防领域

签名 OK、比对 FAIL — 当证明指向另一个交付物

在 LabHub 中继续学习

한국어 원문으로 표시합니다.

목표

폐쇄망에 들어온 산출물과 함께 온 증빙 세 종(CycloneDX SBOM · in-toto Statement · SLSA Provenance)이 정말로 그 산출물을 가리키는지 인터넷 없이 대조하고, 확인한 것과 확인 못 한 것을 나눠 적은 반입 심사 보고서를 남긴다.

왜 중요한가

반입 심사에서 "서명 검증 통과" 는 생각보다 훨씬 좁은 사실이다. 그 명령이 확인한 것은 증빙 문서가 서명된 뒤로 바뀌지 않았다는 것뿐이고, 산출물은 명령에 등장하지도 않는다. 증빙과 산출물을 잇는 것은 subject 의 digest 다. 그래서 문서를 고칠 수 있는 쪽이 서명도 다시 붙일 수 있는 상황에서는, 지문을 다시 계산해 맞춰 보는 한 줄이 절차의 유일한 방어가 된다. 이 실습은 그 한 줄이 없을 때 무슨 일이 일어나는지를 직접 만들어 본다. 서명이 유효한 채로 subject 만 이미 승인된 옛 판을 가리키는 증빙을 만들고, 서명 층과 결속 층이 서로 다른 말을 하는 것을 기록으로 남긴다. 마지막 단계의 보고서는 형식 맞추기가 아니다. 확인한 것과 이 망에서는 확인할 길이 없는 것을 갈라 놓지 않으면, 읽는 사람에게는 전부 확인된 것으로 읽히고 그 오해가 승인 서명까지 따라간다.

단계

  1. 생성 스크립트를 그대로 돌려 /root/supply/drop/ 아래 산출물과 /root/supply/evidence/ 아래 증빙 다섯 장, 그리고 서명 두 개를 만든다.
  2. 산출물 지문을 다시 계산해 Statement 의 subject 와 맞춰 보고 /root/supply/check/subject.txt 에 적는다.
  3. SBOM 의 구성품 목록과 실제 트리를 양방향으로 대조해 /root/supply/check/sbom-diff.json 에 적는다.
  4. Provenance 에서 사실을 뽑고 /root/supply/QUESTIONS.txt 의 질문 여섯 개를 /root/supply/check/provenance.json 에서 가른다.
  5. openssl dgst -sha256 -verify 로 증빙 서명을 확인하고 /root/supply/check/signature.txt 에 적는다.
  6. /root/supply/swap/statement-swapped.json 에 서명은 유효한데 subject 가 옛 판을 가리키는 증빙을 만들고 결과를 /root/supply/check/swap.txt 에 두 층으로 적는다.
  7. 증빙 세 장의 술어를 보고 /root/supply/check/predicates.json 에 accept · hold · reject 를 가른다.
  8. /root/supply/check/attestation-report.json 에 반입 심사용 증빙 대조 보고서를 쓴다.

참고

산출물과 증빙 묶음을 망 안에 재현하기

생성 스크립트를 그대로 돌려 /root/supply/drop/collector-2.4.1.tar.gz 와 /root/supply/drop/payload/ 일곱 파일, /root/supply/archive/collector-2.4.0.tar.gz, 그리고 /root/supply/evidence/ 아래 sbom.cdx.json · statement.json · qa-signoff.json · vendor-release.pub 와 서명 두 개를 만드세요. /root/supply/QUESTIONS.txt 와 /root/supply/REPORT-KEYS.txt 도 함께 만들어집니다.

스크립트는 시드와 묶음 시각을 고정해 두었습니다. 그래야 몇 번을 돌려도 같은 지문이 나오고, 다음 단계의 대조가 사람마다 달라지지 않습니다. 스크립트를 고치지 말고 그대로 쓰세요. 서명 키는 이미 있으면 다시 만들지 않습니다.

받은 파일의 지문을 다시 계산해 subject 와 맞추기

/root/supply/check/subject.txt 에 산출물 지문, Statement 의 subject 이름과 지문, 두 지문의 일치 여부, _type, predicateType 을 적으세요.

subject 는 배열입니다. 원소마다 name 과 digest 가 있고, 규격은 digest 가 반드시 있어야 한다고 못박습니다. 이름은 구분용 꼬리표라 맞춰 봐야 아무것도 확인되지 않습니다. 일치 여부는 YES 또는 NO 한 낱말로 적습니다.

SBOM 과 실제 트리를 양방향으로 대조하기

/root/supply/check/sbom-diff.json 에 SBOM 구성품 수, 트리 파일 수, 완전 일치 수, 문서에만 있는 목록, 트리에만 있는 목록, 지문이 어긋난 목록을 적으세요.

세 종류의 어긋남이 있습니다. 문서에만 있는 것, 트리에만 있는 것, 이름은 양쪽에 있는데 지문이 다른 것. 목록만 맞춰 보는 대조는 세 번째를 통째로 놓칩니다. 경로는 payload 기준 상대 경로로 적고, 구성품은 type 이 file 인 것만 셉니다.

Provenance 로 답할 수 있는 질문과 없는 질문 가르기

/root/supply/check/provenance.json 에 buildType, builder.id, invocationId, 시작·종료 시각, externalParameters 의 키 목록, resolvedDependencies 개수를 적고, /root/supply/QUESTIONS.txt 의 질문 여섯 개를 answerable 과 not-answerable 로 가르세요.

판정 기준은 하나입니다 — predicate 안에 그 사실을 적는 자리가 실제로 있는가. 명세는 externalParameters 를 아래쪽에서 검증하라고, internalParameters 는 플랫폼을 믿으므로 검증할 필요가 없다고 나눠 적습니다. 키 목록에 둘을 섞지 마세요.

서명이 무엇을 덮고 무엇을 덮지 않는지 확인하기

openssl dgst -sha256 -verify 로 두 문서의 서명을 확인하고 /root/supply/check/signature.txt 에 공개키 지문, 두 검증 결과, 서명이 붙은 문서 수와 붙지 않은 문서 수, 서명이 산출물 자체를 덮는지를 적으세요.

검증 명령에 어떤 파일을 입력으로 주었는지 보세요. 산출물은 그 명령에 등장하지 않습니다. 공개키 지문은 PEM 이 아니라 DER 로 바꾼 뒤 뜹니다. PEM 은 헤더와 줄바꿈이 섞여 있어 같은 키인데도 파일마다 해시가 달라질 수 있습니다.

서명은 유효한데 subject 가 다른 것을 가리키는 증빙 만들기

/root/supply/swap/statement-swapped.json 에 술어는 그대로 두고 subject 만 /root/supply/archive/collector-2.4.0.tar.gz 를 가리키게 바꾼 증빙을 만들어 같은 키로 다시 서명하고, 결과를 /root/supply/check/swap.txt 에 두 층으로 적으세요.

원본 증빙은 건드리지 말고 별도 사본으로 만듭니다. 문서를 고친 뒤 다시 서명해야 '서명이 유효한데도' 라는 반례가 성립합니다. 술어까지 바꾸면 다음 단계의 '모르는 술어' 문제와 섞여 요점이 흐려집니다. 지문은 Statement 에서 옮기지 말고 그 파일에서 다시 계산해 확인하세요.

모르는 술어를 통과도 거절도 아닌 자리에 두기

/root/supply/check/predicates.json 에 우리가 읽을 줄 아는 술어 목록과, 증빙 세 장(evidence/statement.json · evidence/qa-signoff.json · swap/statement-swapped.json)의 술어·아는 술어인지·subject 일치 여부·판정을 적으세요.

판정은 두 값에서 따라 나옵니다. 읽을 줄 모르는 술어는 통과의 근거가 될 수 없고, 그렇다고 그 자체가 거절의 근거도 아닙니다. in-toto 의 파싱 규칙은 정책을 '나쁜 증빙이 있으면 막기' 가 아니라 '좋은 증빙이 있어야 통과' 로 쓰라고 권합니다. 판정 값은 accept · hold · reject 셋뿐입니다.

반입 심사에 붙일 증빙 대조 보고서 쓰기

/root/supply/check/attestation-report.json 에 산출물과 그 지문, /root/supply/evidence/ 아래 여섯 파일의 지문, 확인한 것과 확인 못 한 것, 3단계에서 센 어긋남 세 가지, 7단계에서 보류한 증빙, 그리고 판정을 적으세요.

verified 와 not_verified 에는 /root/supply/REPORT-KEYS.txt 의 낱말 여덟 개를 빠짐없이 겹치지 않게 나눠 넣습니다. 가르는 기준은 하나입니다 — 이 파드 안에서 내가 직접 계산했거나 검증했는가. 남이 문서에 적어 준 주장은 확인이 아닙니다. 판정 세 값의 뜻도 같은 파일에 적혀 있습니다.