[qubes-users] Re: External Fully Encrypted SSD Drive. What do you think?

[Mark Fernandes]

On Tuesday, 28 July 2020 at 12:09:39 UTC+1 load...@gmail.com wrote:

>
> ...
> I am thinking now to buy a Macbook Pro 16' and use this laptop in 2 
> different ways:
>
> 1. *Mac OS* for non-working tasks on internal drive.
> 2. *Qubes OS* for all working process on external encrypted drive.
>
>
> So for External Encrypted Drive I chose:
> ...
>
>
>
> *So I have 2 questions:*
>
> *1. Is this enough for comfort using Qubes OS with this speed of SSD?2. 
> What kind of Hardware Encrypted Drive do you know which has more speed 
> capacity?*
>
>
> P.S.
> I know that most of you could tell me that this is not very smart to do 
> this way, but I have my own reasons why I need external and encrypted 
> drive. When I will finish this setup I will write full guide how I am using 
> Qubes OS and hope it would helps someone to understand which way to use is 
> better for each one.
>


Hello "load...@gmail.com",

Just been perusing the email conversation so far with regard to your 
enquiry. Interesting thoughts. Regarding writing a full guide, I have 
produced some documentation on End-user Computer Security on the Wikibooks 
site here . I 
would like it to be a general free repository of knowledge, guidance, and 
wisdom. If you are able to add to it in regard to your full guide, that may 
be quite helpful for the general community--even just posting a link to 
your guide there, would probably be helpful.

In respect of which encrypted SSD drive to use, I have no suggestions. 
However, the thought has occurred to me that you might get more security if 
you load Qubes to RAM from a DVD drive. Some info on why this may be the 
case, is shown here 
.
 
Not sure whether it is feasible though, and your "encrypted SSD" plan might 
be sufficient for your purposes.


Kind regards,


Mark Fernandes















 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0393eb65-cb2e-483a-90b9-9b1a59141df6n%40googlegroups.com.

Re: [qubes-users] Re: External Fully Encrypted SSD Drive. What do you think?

[brendan . hoar]

On Wednesday, July 29, 2020 at 2:33:29 AM UTC-4, Qubes wrote:
>
> On 7/29/20 1:56 AM, ludwig...@gmail.com wrote: 
> > *What if it saves a spare set of encryption keys somewhere in its flash 
> for 
> > the "lawful investigator" to find?* 
>  > 
> I am not aware of any proof to support this line of thinking. 
>

My position: if you have critical secrets, then your solution should be 
combining belt and suspenders, that is, you should apply layers of 
encryption with different keys and passwords.

1. First if your main drive supports it, enable hardware encryption. Even 
if you don't trust the device manufacturer (perhaps they, as posited aove 
"save a spare set of encryption keys somewhere in its flash"*), it is still 
an additional layer of protection. In particular, the password/pin should 
be different than password/pin used for LUKS in section #2 for separation 
of trust. This can also provide some boot drive tamper protection by at 
least a subset of attackers.
  alternate 1a. boot qubes off of a a SED SATA/NVME drive: implement using 
something like sedutil or even TCP Opal Class 0 encryption if your BIOS 
supports it (Class 0 leverages the TCG Opal SED engine using an ATA 
Password with some bits of security lost due to password filtering 
depending upon BIOS implementation) and you semi-trust the drive 
manufacturer. 
  alternate 1b. boot qubes off of a USB drive with a hardware encryption 
bridge/enclosure and a pinpad password (very long is better, if supported). 
Again, you must semi-trust the manufacturer of the encryption engine, of 
course.

2. Set up qubes with a LUKS layer and a password (pretty much, the standard 
install) on the drive you have configured above. You must semi-trust the 
Qubes, LUKS and linux developers, of course (open source allows audit, so 
either do it yourself or...hope/verify someone else did). Password should 
be different than the hardware device password in #1 for separation of 
trust.

Above are the basic belt and suspenders. 

Section #1 utilizes the hardware encryption you may already have and gives 
you a bonus of some additional protection against modification of the boot 
data on the drive. The TCG Opal Class 0 approach should not interfere with 
installation of AEM. Standard TCG Opal via sedutil requires additional 
custom work to support AEM.

Section #2 gives you the more trusted layer of software encryption.

Now for some additional soap-box comments, generally under the heading of 
Qubes currently != anti-forensics: 

1. Disposable VMs do not promise any anti-forensics properties if your 
system is up and running (that is, the LUKS volume is mounted). Disposable 
VMs have a primary purpose which is* not* to "forget" information, but 
rather to prevent attacks inside a VM from being permanent (prevent 
foothold) and partition your data so that attacks within the disposable VMs 
cannot accessing your data. Typically**, the data used in a disposable VM 
remains on the storage device even after the VM is shutdown until that 
space is needed again to store something else.

2. Attaching devices to dom0 puts dom0 at risk. Even unmounted devices can 
be unintentionally automatically mounted or at least partition/volume 
scanned when running various toolkit-based executables such as thunar 
(xfce's file explorer equivalent) or anything else that invokes the xfce 
windowing toolkit components or similar in dom0.

3. Attaching devices to dom0 can pollute dom0 memory/storage with content 
from that device. For the above reasons, among others.

4. Fragments of VM sessions can end up in the dom0 or GUIVM user folder 
and/or system/application logs. E.g. one can find the window titles of domU 
VM windows (including disposable VMs or even VMs stored in secondary pools) 
stored in the dom0 main user's dot (hidden) directories.

5. Until very recent changes to the qubes thin pool driver (available in 
4.1 only?), disposable VM's volatile volumes on LVM were always being 
stored in the primary pool. EVEN if the disposable VM and the disposable VM 
templates were stored in a secondary pool on a separately encrypted device. 
This behavior was surprising to many and I consider it a defect.

Hope this is helpful,
Brendan

* Most SED/TCG OPAL drives can be fully rekeyed using one or more of the 
following ATA SANITIZE CRYPTO EXT, ATA SECURE ERASE ENHANCED, or a PSID 
REVERT. Some support all three invocations, some a subset. Some 
manufacturers go out of their way to *only* rekey (and not erase) when 
invoking the first two, so you can check to see your data is irrevocably 
scrambled after invocation. Ok, maybe you don't trust the drive 
manufacturer to not log all keys in the clear for entities they have 
relations with? Fine. But at least get in the practice of rekeying the 
drive a couple times before putting data on it that way if they're only 
storing the factory key, well...(takes off tin foil hat).

** Note that the Qubes thin volume storage driver will attempt to 

Re: [qubes-users] Re: External Fully Encrypted SSD Drive. What do you think?

[Steve Coleman]

On Wed, Jul 29, 2020, 2:33 AM Qubes  wrote:

> On 7/29/20 1:56 AM, ludwig...@gmail.com wrote:
> > *What if it saves a spare set of encryption keys somewhere in its flash
> for
> > the "lawful investigator" to find?*
>  >
> I am not aware of any proof to support this line of thinking.
>

In the case of an Opal 2.0 encrypted drive the key is *never* stored on the
device. That is a requirement in oder to meet the defined Opal standard,
and any manufacturer needs to prove that they meet that standard by
submitting to a gauntlet of independently run certification tests. They
can't fake passing these tests.

The key(s) are generated at runtime by combining some internally generated
entropy plus the user supplied 256 bit password. If you reset the drive
then the internal entropy is regenerated as well, so even when having the
users old password one can not dynamically generate the origional
decryption key.

This basically means that if you build in a failsafe mechanism into your
software, to detect tampering, and flip the bits of your key and reset the
drive, that data is not recoverable even when provided the prior password.
Good luck at ever recovering that data even for your own purposes. Your
"lawfull investigator" has no better chance than the KGB at ever
recovering/seeing your data.

For a dead man's kill switch, Just reset the device and force a power down
and that data is no longer recoverable.

If you do not fully reset the device and only powered down, then the data
is only recoverable using the users 256 bit (hopefully randomized)
password. Even then the drives internal logic will add an increasing delay
with each invalid passrord attempt is made thus making even brute forcing
the password completely impractical.

Adding software encryption on top of that hardware layer encryption is a
good belt and suspenders approach if you really don't trust the device
itself to fully protect you.

I had the pleasure of working with one of the origional designers of this
standard, for almost a year while developing some very custom solutions
with these devices. While the first Opal 1.0 devices certainly had some
quirks, I trust the current line of Opal 2.0 SSD Sed devices to keep your
data both safe and confidential.



-- 
> You received this message because you are subscribed to the Google Groups
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/0a24d013-6bca-4d66-3e4c-1d6ab13fd3e8%40ak47.co.za
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAJ5FDnhmpeygJPvp1UQax2ji2jz7oW13xfW4QDZ1aB_HUtNk8Q%40mail.gmail.com.

Re: [qubes-users] Re: External Fully Encrypted SSD Drive. What do you think?

[Qubes]

On 7/29/20 1:56 AM, ludwig...@gmail.com wrote:

*What if it saves a spare set of encryption keys somewhere in its flash for
the "lawful investigator" to find?*

>
I am not aware of any proof to support this line of thinking.

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0a24d013-6bca-4d66-3e4c-1d6ab13fd3e8%40ak47.co.za.

[qubes-users] Re: External Fully Encrypted SSD Drive. What do you think?

[ludwig...@gmail.com]

"*Hardware Encrypted Drive do you know which has more speed capacity"*

*can you trust the drive?*

*What if it saves a spare set of encryption keys somewhere in its flash for 
the "lawful investigator" to find?*
*So do "hardware assisted crypto" only in addition to your crypto you trust 
in, which is open source crypto which has*
*been reviewed and reached a state of maturity.*



On Tuesday, July 28, 2020 at 11:09:39 AM UTC load...@gmail.com wrote:

>
> Hi everyone,
>
> I am thinking now to buy a Macbook Pro 16' and use this laptop in 2 
> different ways:
>
> 1. *Mac OS* for non-working tasks on internal drive.
> 2. *Qubes OS* for all working process on external encrypted drive.
>
>
> So for External Encrypted Drive I chose:
> https://istorage-uk.com/product/diskashur2/
>
> *One of the important tech specs is SSD Speed:*
> 361MB/s *Read*
> 358MB/s *Write*
>
>
>
>
> *So I have 2 questions:*
>
> *1. Is this enough for comfort using Qubes OS with this speed of SSD?2. 
> What kind of Hardware Encrypted Drive do you know which has more speed 
> capacity?*
>
>
> P.S.
> I know that most of you could tell me that this is not very smart to do 
> this way, but I have my own reasons why I need external and encrypted 
> drive. When I will finish this setup I will write full guide how I am using 
> Qubes OS and hope it would helps someone to understand which way to use is 
> better for each one.
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3f00470b-2866-4ec5-a73f-93a2a314fb53n%40googlegroups.com.