사용 사례는 무엇인가요?

호스트 OS를 라이브 모드로 사용하는 주요 사용 사례는 장기간 민감한 활동(즉, 하드 드라이브에 민감한 파일을 저장하려는 경우)에 사용하는 것입니다. 보시다시피, 호스트 OS를 라이브 모드로 사용하는 것은 사실상 부인 가능성에 대한 엄격한 요구 사항입니다.

민감한 사용에 대해 이야기할 때, 우리는 부인 가능성의 필요성에 대해 이야기합니다. 즉, Veracrypt의 숨겨진 볼륨을 사용하여 부인 가능한 암호화를 사용해야 한다는 것을 의미합니다.

이론적으로 숨겨진 볼륨이 닫힌 후에는 그 자체로 그 존재를 증명하는 것이 불가능하며, 그 존재에 대한 증거가 없다면 부인 가능성은 유지됩니다.

하지만 문제는 호스트 OS 측에서 제어해야 할 변수가 더 많다는 것입니다. 시스템 로그, 커널 로그, 소프트웨어가 디스크에 기록하는 다양한 비표준 로그 파일, 심지어 RAM 자체의 내용까지도 숨겨진 볼륨의 존재를 증명하는 데 사용될 수 있습니다.

컴퓨터를 일반적인 공개, 비공개, 익명 활동에 사용할 때는 일반적으로 이러한 사항에 신경 쓸 필요가 없습니다. 하지만 호스트 OS는 기기가 압수될 경우 불리하게 사용될 수 있는 잠재적인 법의학적 증거의 보고이므로, 특히 민감한 용도의 경우 호스트 OS를 철저히 관리해야 합니다.

모든 로그, 모든 커널 로그, 모든 비표준 시스템 로그를 수동으로 삭제하고 RAM 내용을 수동으로 덮어쓸 수도 있지만, 이 작업은 너무 번거롭고 무언가를 놓칠 가능성이 높습니다. 따라서 간단한 해결책이 있습니다. 바로 호스트 OS를 라이브 모드로 사용하는 것입니다.

라이브 모드 덕분에 전체 호스트 OS를 RAM에 직접 로드할 수 있어 시스템 디스크에 아무것도 쓸 필요가 없습니다(시스템 로그, 커널 로그, 비표준 로그 없이 RAM 내용만 신경 쓰면 됩니다).

모든 것이 RAM에 로드되므로 컴퓨터를 재부팅하여 RAM 내용을 모두 삭제하기만 하면 됩니다. 이렇게 하면 숨겨진 볼륨의 존재를 뒷받침하는 모든 증거(그리고 잠재적인 증거)를 한 번의 간단한 작업으로 효과적으로 삭제할 수 있습니다.

아직 Qubes OS를 권장하지 않는 이유는 무엇인가요?

요약: 호스트 OS 계층에 라이브 모드 및 램 삭제 기능이 없기 때문에 장기간 민감한 용도로 사용하는 저희의 거부 관련 튜토리얼에 적합하지 않습니다.

Qubes OS란 무엇인가요? Qubes OS는 구획화를 통해 보안을 제공하는 운영 체제이며, 자세히 살펴보면 저희가 권장하는 것과 많은 유사점을 발견하실 수 있습니다. 주요 차이점은 하이퍼바이저가 Libvirtd KVM/QEMU가 아닌 XEN 기반이고, 호스트 OS가 Debian이 아닌 Fedora 기반이며, 인터넷 사용 세분화 모델이 약간 더 발전되어 있다는 것입니다(예를 들어, USB 장치, 네트워킹 스택, 방화벽 규칙, 디스플레이 관리자 및 시스템 관리를 호스트 OS에 직접 유지하는 저희 권장 사항과 달리 별도의 VM에 분리합니다). 단지 위협 모델이 다를 뿐입니다.

Qubes OS를 정확히 어떤 용도로 권장하시나요? 오해하지 마세요. Qubes OS는 비공개 소스 소프트웨어 부족으로 개인 사용에 적합하고, 익명 사용(Tor, Whonix 사용, 다중 ID 작업을 위한 VM 기반 분할)에도 적합하기 때문에 Opsec 권장 사항의 3분의 2에 해당합니다.

Qubes OS를 권장하지 않는 이유는 무엇일까요? 안타깝게도 Qubes OS는 라이브 모드와 램 삭제 기능(실제로는 필수 기능)이 없기 때문에 장기적인 Deniability 튜토리얼을 위한 호스트 OS로 적합하지 않습니다. 따라서 Qubes OS는 비공개 및 익명 사용에는 기껏해야 적합하다고 생각합니다. 하지만 제가 보기에는 라이브 모드와 램 삭제 기능이 있는 주요 Kicksecure 호스트 OS와는 달리 장기적인 민감한 용도로는 사용할 수 없습니다. (관련 포럼 스레드) 이 스레드에서 qubes 포럼 관리자는 호스트 OS에 기억상실/라이브 모드 기능이 없다고 설명했습니다. 즉, Qubes OS를 호스트 OS로 사용하는 상태에서 민감한 VM 설정을 복제하려고 시도하면 시스템 드라이브에 존재에 대한 법의학적 증거를 남기지 않고는 Veracrypt 숨겨진 볼륨을 열 수 없게 되어 사실상 부정 Opsec 요구 사항에 적합하지 않게 됩니다. 요약하자면, 만약 적대적인 세력이 지금 당장 문을 부수고 들어온다면 다음과 같은 상황이 벌어질 것입니다. 1) 그 안에 있는 모든 암호화된 볼륨(LUKS)을 잠금 해제해야 합니다(그 존재를 부인할 수 없기 때문입니다). 2) Qubes 호스트 OS에 저장했을 수 있는 Veracrypt 숨겨진 볼륨의 존재를 부인할 수 없기 때문입니다. 3) Veracrypt 숨겨진 볼륨도 잠금 해제해야 합니다(그 존재를 부인할 수 없기 때문입니다). 4) Veracrypt 숨겨진 볼륨에 저장하려고 시도했을 수 있는 모든 민감한 콘텐츠(이 경우에는 실제 민감한 VM)가 노출됩니다.

결론적으로: KickSecure 팀이 자사 OS에 라이브 모드와 램 와이프를 구현한 것처럼 Qubes가 라이브 모드와 램 와이프를 모두 구현하면 입장을 바꿀 수도 있지만, 그때까지는 KickSecure 호스트 OS 권장 사항을 고수할 것입니다.

What is the usecase ?

The main usecase of using your Host OS in live mode, is that you want to use it for long term sensitive activities (meaning, you want to save sensitive files on a harddrive). As you're going to see, using the Host OS in live mode is effectively a hard requirement for deniability.

When we are talking sensitive use, we are talking about our need of Deniability. Which means that we need to use deniable encryption using Veracrypt's hidden volumes:

In theory it is impossible to prove the existence of the hidden volume by itself once it is closed, and if there is no proof of it's existence our deniability is maintained.

But the issue is that we have more variables that we also need to keep under control, on the Host OS side you have system logs, kernel logs , the various other non-standard log files that software is writing on the disk, and even the content of the RAM itself can be used to prove the existence of a hidden volume.

Now when you are using your computer for regular public, private and anonymous activities, normally you don't need to care about those things. But the Host OS is a potential goldmine of forensic evidence to be used against you if the device were to be seized, so for sensitive use specifically we need to take care of it.

Now you could start to manually erase all logs, all kernel logs, all non-standard system logs, manually overwrite the RAM contents, but this is going to be way too tedious and you're likely to miss something. So we have one simple solution: use the Host OS in live mode.

Thanks to live mode, we are able to load the entire Host OS in RAM directly , allowing us to avoid writing anything on the system disk (no system logs, no kernel logs, no non-standard logs, only ram contents to worry about)

And since everything is loaded inside the RAM, all we need is to reboot the computer to wipe all of the RAM contents , effectively erase all forensic evidence (and all potential forensic evidence) of the existence of the hidden volume in one simple action.

Why are we not recommending Qubes OS yet ?

TLDR: it's because of the lack of live-mode and ram-wipe features on the Host OS layer, which makes it unsuitable for our deniability-related tutorials for long-term sensitive use.

What is Qubes OS ? Qubes OS is an operating system aimed at providing security through compartmentalization, and if you're looking carefully you'll see alot of similarities with our recommendations: The main differences are that the hypervisor is XEN-based instead of being based on Libvirtd KVM/QEMU, and the host OS is based on fedora instead of debian, and their internet use segmentation model is slightly more advanced (for instance they isolate the usb devices, the networking stack, the firewall rules, the display manager, and the system management in separate vms, rather than our recommendation of keeping those on the Host OS directly.) They simply have a Different threat model.

What are we recommending Qubes OS for exactly ? Don't get us wrong, we could easily recommend Qubes OS for 2 thirds of our opsec recommendations, being that it is suitable for private use (lack of closed-source software), and suitable for anonymous use (use of Tor and Whonix and vm-based segmentation for multi-identity work).

What are we not recommending Qubes OS for ? Sadly, Qubes OS is not suitable as a Host OS for our long-term Deniability tutorials because it lacks the live mode and ram-wipe feature (which is actually a hard requirement), therefore we consider Qubes OS as suitable for Private and Anonymous uses at best, but as far as i'm concerned, IT CANNOT be used for long-term sensitive use unlike with our main Kicksecure Host OS recommendation, which has the live-mode + ram wipe feature. (related forum thread) In this thread the qubes forum moderator basically explains that the host OS lacks the amnesiac / live mode feature, meaning that if you attempted to replicate our Sensitive VM setup but with having Qubes OS as a Host OS, you would be unable to open the veracrypt hidden volume without leaving forensic evidence of it's existance on the system drive, effectively making it unsuitable for our deniability opsec need. To summarize, if an adversary were to bust down your door right now, you would: 1) be forced to unlock every encrypted volume (LUKS) it contains (since you cannot deny their existance) 2) be unable to deny the existance of the veracrypt hidden volume you may have stored on the Qubes Host OS 3) be forced to unlock the veracrypt hidden volume aswell (since you're unable to deny its existance) 4) reveal all of the sensitive contents that you may have tried to store inside the veracrypt hidden volume, in our case, it would be the actual sensitive VM.

In conclusion: we may change our stance once they implement both live-mode and ram-wipe just like how kicksecure team implemented it for their OS, but until then we'll stick to our kicksecure host OS recommendations.

출처 니힐리즘 opsec 블로그