"확인 키를 외부에 저장해야 하는 경우" Journalctl은 어떻게 로그에 서명합니까?

"확인 키를 외부에 저장해야 하는 경우" Journalctl은 어떻게 로그에 서명합니까?
$ man journalctl
...
--setup-keys
Instead of showing journal contents, generate a new key pair for Forward Secure Sealing (FSS). This will generate a
sealing key and a verification key. The sealing key is stored in the journal data directory and shall remain on the
host. The verification key should be stored externally. Refer to the Seal= option in journald.conf(5) for
information on Forward Secure Sealing and for a link to a refereed scholarly paper detailing the cryptographic
theory it is based on.
...
--verify
Check the journal file for internal consistency. If the file has been generated with FSS enabled and the FSS
verification key has been specified with --verify-key=, authenticity of the journal file is verified.

--verify-key=
Specifies the FSS verification key to use for the --verify operation.

내가 아는 한, PKI 시스템에 로그인하는 것은 개인 키가 있는 경우에만 가능합니다.

제가 아는 한, "인증키는 외부에 보관해야 합니다." 개인키(?)는 다른 곳에 보관해야 할까요?

묻다:그렇다면 이 경우 암호화된 로그 메시지는 어떻게 서명됩니까?

내가 아는 한, 암호화된 로그가 서명되지 않은 경우 공격자는 수정된 로그를 암호화하여 로그를 위조할 수 있으며 로그는 서명되지 않았으므로 허용됩니다. 그러나 공격자가 서명할 수 있으므로 개인 키를 그곳에 보관하는 것도 좋지 않습니다.

답변1

먼저 우리는 질문의 주제가 제시하는 의견 중 일부를 이해해야 합니다.LWN 기사: 전방 안전 씰

  • FSS [Forward Security Seal]은 최소한 단일 시스템을 사용하여 변조를 감지하는 방법을 제공합니다.외부 로깅이 제공할 수 있는 모든 보장을 제공하지는 않습니다..

  • systemd 로깅으로 처리되는 바이너리 로그는 주기적으로 "봉인"될 수 있습니다. 봉인은 봉인 전 변조를 감지할 수 있도록 로그 데이터에 대한 암호화 작업입니다.

  • FSS의 알고리즘은 FSPRG(Forward Secure Pseudo-Random Generator)를 기반으로 합니다.

  • 하나의 키는 시스템에 보관되는 "봉인 키"이고, 다른 하나는 "확인 키"이므로 다른 곳에 안전하게 보관해야 합니다. FSPRG 메커니즘을 사용하면 되돌릴 수 없는 프로세스를 통해 새로운 봉인된 키가 주기적으로 생성됩니다. 변경 후에는 기존 키가 시스템에서 안전하게 제거됩니다.

  • 검증 키는 주어진 기간 동안의 봉인 키를 계산하는 데 사용될 수 있습니다. 이는 공격자가 현재 봉인 키(다음 봉인 작업에 사용될 수 있음)에만 액세스할 수 있는 반면 관리자는 이전 로그 파일 봉인을 확인하기 위해 봉인 키를 안정적으로 생성할 수 있음을 의미합니다. 마지막 봉인 전에 로그 파일 항목을 변경하면 유효성 검사가 실패하게 됩니다.

그런 다음 질문에 대답하려면 다음을 수행하십시오.

Q: 그렇다면 이 경우 암호화된 로그 메시지는 어떻게 서명되나요?

로그 파일은 실제로 암호화되거나 서명되지는 않지만밀봉하다. 이는 특정 암호화 작업을 통해 수행됩니다. 밀봉 작업의 두 가지 주요 특성은 다음과 같습니다.

1) 전방보안:

적이 과거 로그 항목을 위조하려고 시도하는 경우 현재 키를 학습해도 아무런 이점을 얻을 수 없습니다.

2) 검색 가능성:

감사자는 계산 비용을 거의 들이지 않고도 순서나 액세스 패턴에 상관없이 로그 항목의 무결성을 확인할 수 있습니다.

자세한 내용은 다음 기사에 나와 있습니다.실용적인 보안 로깅: Giorgia Azzurra Marson 및 Bertram Poettering의 검색 가능한 순차 키 생성기.

소스코드도 볼 수 있어요fsprg.c

관련 정보