Tails

#8 Updated by sycamoreone 2015-06-10 20:42:35

I once promised to ask around about this issue and got directed to the randomness-generation mailing list.

I asked a question there, but only little feedback.

#11 Updated by emmapeel 2015-08-04 02:32:28

Dr_Whax wrote:
> I’ll lead the discussion with a couple of cryptographers so we can come up with a plan to integrate it.
During yesterday’s contributors meeting[1], sycamoreone said that was iinterested on this, so maybe he wants to join that conversation.

[1] https://tails.boum.org/contribute/meetings/201508/

#16 Updated by intrigeri 2016-02-21 14:33:15

One (crazy?) option could be to store a device-specific seed in the attributes bits of the Tails system partition’s GPT entry. IIRC there are 16 bits there we could use (but better reserve a few of them for future uses). This way, even without persistence one might get something better than what we currently have. Whether we want to update this seed on the drive during boot and/or shutdown, when the persistence is enabled/disabled, is left as an exercise for the reader :) Now, if we’re ready to do that, of course we can as well have Tails Installer put the seed inside the system partition, if it’s more practical. But it may be harder to update it.

#17 Updated by sajolida 2016-02-22 08:31:17

Just to understand better the proposal: what would be the advantages of using the GPT partition table over storing it in a file on the system partition?

#18 Updated by intrigeri 2016-02-22 16:29:34

> Just to understand better the proposal: what would be the advantages of using the GPT partition table over storing it in a file on the system partition?

No idea yet :)

#19 Updated by intrigeri 2016-06-09 13:14:51

So, kurono posted another implementation idea to the blueprint (use Tails Installer), and dgoulet + sycamoreone had yet another idea (Feature #5650#note-21): “query the amount of entropy added to the pool. It would be possible to start both services [haveged and rngd] early in the boot process and then block until enough entropy is available. We then wouldn’t need to var/.../random-seed files”.

#20 Updated by cypherpunks 2016-06-12 05:31:49

intrigeri wrote:
> One (crazy?) option could be to store a device-specific seed in the attributes bits of the Tails system partition’s GPT entry. IIRC there are 16 bits there we could use (but better reserve a few of them for future uses). This way, even without persistence one might get something better than what we currently have. Whether we want to update this seed on the drive during boot and/or shutdown, when the persistence is enabled/disabled, is left as an exercise for the reader :) Now, if we’re ready to do that, of course we can as well have Tails Installer put the seed inside the system partition, if it’s more practical. But it may be harder to update it.

16 bits is pretty useless for randomness… That’s a keyspace of just 65536. Considering the system already gets randomness from things like the MAC address and other hardware, I think that would just add unnecessary complexity without any benefit. Now, there should be plenty of room in the MBRs (both the backup and main). I wonder how much entropy could be added by exploiting redundancy in the x86 instruction set… You could probably modify the executable on the fly at each boot, replacing each opcode for an equivalently functional but different one. I don’t know much about GPT (I only use MBR myself) other than that they have two backup MBRs, but I assume those backup MBRs are still executable? Either way, there’d be plenty of room for at least 128 bits of persistent data, whether in stego-style x86 opcode redundancy, or just unused space between various places.

Or hell, just change the UUID at each boot. :P

#21 Updated by cypherpunks 2016-07-16 03:50:36

cypherpunks wrote:
> Now, there should be plenty of room in the MBRs (both the backup and main). I wonder how much entropy could be added by exploiting redundancy in the x86 instruction set… You could probably modify the executable on the fly at each boot, replacing each opcode for an equivalently functional but different one.

Each MBR contains up to 446 bytes of executable code (though typically only 436 bytes are used). The best method of exploiting x86 redundancy that I know of is Hydan, with 1/110 for an encoding efficiency. 446 * 2 / 110 * 8 ~= 65, so only about 65 bits could be stored in two MBRs. Not quite enough for a cryptographic seed.

Would it be appreciated if I created a PoC which stored persistent seeds between the end of the executable code in each MBR and the beginning of the UUID and partition table data, which should contain 80 bits each? Or alternatively (and more easily), have it stored on the system partition? The only downside I see to having it stored on the system partition are for people who like to checksum their drive before they boot it. It’s much easier to ignore changes to GPT areas than it is to ignore filesystem changes (which extend to metadata entries far beyond a set offset at the beginning of the drive). Other than that, storing it on the FAT32 filesystem is certainly easier to do and less prone to accidents.

#22 Updated by intrigeri 2016-07-30 04:33:05

> Other than that, storing it on the FAT32 filesystem is certainly easier to do and less prone to accidents.

+1

#25 Updated by intrigeri 2017-04-02 11:31:52

DrWhax, bertagaz, sycamoreone: this topic seems to be stalled since November; perhaps it’s time to make it clear what the next step is, and who committed to make it happen?

#27 Updated by Anonymous 2017-06-30 10:30:43

Ping @drwhax, see previous comment for open questions please :)

#28 Updated by intrigeri 2017-08-19 13:21:05

Linux will soon support adding the kernel command line as a source of randomness. One of the corresponding commit messages explains how Android uses this. I bet that’ll be the best way for us to go as it triggers much earlier than anything we can do in userspace. Next step: check how this can be integrated into our syslinux config and install/upgrade process.

#30 Updated by intrigeri 2017-09-07 06:16:28

intrigeri wrote:
> Linux will soon support adding the kernel command line as a source of randomness. One of the corresponding commit messages explains how Android uses this.

… except this was broken initially. It’s fixed in Linux 4.13 (security things in Linux v4.13, commit.

#32 Updated by intrigeri 2017-11-25 20:30:17

intrigeri wrote:
> intrigeri wrote:
> > Linux will soon support adding the kernel command line as a source of randomness. One of the corresponding commit messages explains how Android uses this.
>
> … except this was broken initially. It’s fixed in Linux 4.13 (security things in Linux v4.13, commit.

… and improved in Linux 4.14.

#34 Updated by Anonymous 2018-08-18 13:15:44

intrigeri wrote:
> intrigeri wrote:
> > intrigeri wrote:
> > > Linux will soon support adding the kernel command line as a source of randomness. One of the corresponding commit messages explains how Android uses this.
> >
> > … except this was broken initially. It’s fixed in Linux 4.13 (security things in Linux v4.13, commit.
>
> … and improved in Linux 4.14.

also see blueprint under “See also” for an analysis by the german IT security ministry about this.

#40 Updated by intrigeri 2019-08-11 15:17:03

(Turns out we don’t need a persistent volume to achieve what we want, so I’m closing this ticket which was about a specific solution based on persistence.)