요약

  • Muhammad Usama Sardar는 10월 27일 RIPE 93에서 TLS 악수 안에 원격 증명을 넣는 방식을 문제 삼았다. Cocos AI의 Intel TDX 경로는 재사용했거나 일치하지 않는 세션 값을 가진 증거를 시험에서 받아들였고, 악수 뒤 응용 데이터가 풀렸다.
  • 다른 Cocos AI 경고문은 AMD SEV-SNP 경로에서 기대 값을 빠뜨리면 엉뚱한 증거가 통과할 수 있다고 적었다. 0.9.0은 악수 뒤 증명으로 옮겼고, IETF SEAT 헌장은 연결마다 새로움을 확인하도록 요구한다.

출입증은 번듯했다. 문제는 오늘 들어온 손님의 옷에 달린 출입증이 아니었다는 점이다. Cocos AI가 직접 낸 Intel TDX 보안 공지에 따르면 검사기는 현재 TLS 세션을 식별할 값을 받았지만 시험 대상 경로는 그 값을 하드웨어 보고서 검증 정책에 넣지 않았다. 재사용되거나 일치하지 않는 reportData를 가진 외부 보고서가 현장 시험을 통과했고, 악수가 끝나자 응용 데이터가 나갔다.

RIPE 93 공식 발표 일정은 Sardar의 발표를 27일로 기록한다. 그가 따져 묻는 것은 속도보다 통제다. 증명을 악수 안에 앞당겨 넣으면 절차는 더 복잡해진다. 그런데 이번 제품 경로에서는 정작 그 증거가 지금 연결의 것인지 확인할 비교가 빠졌다. 악수의 성공과 승인 근거의 성공은 다른 이야기다.

Cocos AI의 두 번째 공지는 AMD SEV-SNP를 다룬다. 0.8.2에서는 호출자가 비어 있지 않은 기대 ReportData를 보낼 때만 검증 정책에 그 값이 설정됐다. 값을 빠뜨리면 현재 연결과 관계없는 증거를 받아들일 수 있었다. 비어 있지 않은 값을 보내면 불일치를 거부했다. 회사는 0.9.0에서 악수 이후 증명으로 옮겼다고 밝혔다.

Edgeless Systems의 Contrast 공지는 또 다른 신원 혼동을 보여준다. 공지에 적힌 통신 가로채기와 보고서 위조 또는 비밀 추출 조건에서, 이전 버전은 측정값이 맞는 다른 기계의 유효한 보고서를 받아들일 수 있었다. 1.16.0은 허용할 하드웨어 ID 목록을 도입했다. 보고서가 유효한지, 기계가 맞는지, 세션이 새로운지는 각각 물어야 한다.

IETF SEAT 작업반 헌장은 증거를 TLS 연결에 묶고, 연결별 새로움을 확인할 수 있게 하며, 규격을 쓰는 동안 형식 분석을 병행하도록 한다. 오래된 보고서, 빈 기대 값, 다른 기계의 보고서를 차례로 내밀어 보면 그 약속을 시험할 수 있다. 데이터가 문 안에 남아 있어야 배지의 효력이 입증된다.