Opened 9 years ago

Closed 2 years ago

#2653 closed enhancement (wontfix)

Support more stable guards for live CDs

Reported by: nickm Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client needs-proposal
Cc: anonym@…, mk@…, intrigeri@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Since livecd environments don't have persistent storage across sessions, they can't keep guard nodes across, and as such don't get the benefit from them.

This may be fixable. Suppose that the livecd gathers a set of system hardware information (MAC address, PCI stuff, etc), and hashes it into a "Guard Seed". Or the user could run a small program before burning the cd that sets a random seed on the disk. The Tor client could then be configured to pick its guards based on the seed. This would give the user similar guards across invocations, to avoid guard churn.

One (approximate) solution is to pick guard nodes based on the first N nodes sorted by H(Seed|NodeID). This doesn't do weighting correctly, though.

A better design and a Proposal are probably needed. Posting this here so we don't lose track of it entirely.

(rransom helped develop this idea.)

Child Tickets

Change History (16)

comment:1 in reply to:  description ; Changed 9 years ago by rransom

Replying to nickm:

Since livecd environments don't have persistent storage across sessions, they can't keep guard nodes across, and as such don't get the benefit from them.

This may be fixable. Suppose that the livecd gathers a set of system hardware information (MAC address, PCI stuff, etc), and hashes it into a "Guard Seed". Or the user could run a small program before burning the cd that sets a random seed on the disk. The Tor client could then be configured to pick its guards based on the seed. This would give the user similar guards across invocations, to avoid guard churn.

We really need the 'guard selection seed' to have enough entropy to be unpredictable to attackers. Otherwise, an attacker can guess a user's seed and choose a relay's identity key so that it will become one of the user's guard nodes at some time in the future.

One (approximate) solution is to pick guard nodes based on the first N nodes sorted by H(Seed|NodeID). This doesn't do weighting correctly, though.

We can do weighting by computing H(GuardID | 0), H(GuardID | 1), ..., H(GuardID | GuardWeight - 1) for each guard, and then choosing the closest guard to H(Seed | 0), the closest not-yet-chosen guard to H(Seed | 1), and so on.

Further improvements are needed to make GuardIDs seed-dependent, make each guard's GuardID change at pseudo-random times, and possibly make each guard-selection value (the H(Seed | i) above) change at pseudo-random times as well.

comment:2 Changed 9 years ago by nickm

Hm. An extra track on the livecd, full of random bits, would be a great way to do a seed. I'm not sure how to best do that, though.

comment:3 in reply to:  2 Changed 9 years ago by rransom

Replying to nickm:

Hm. An extra track on the livecd, full of random bits, would be a great way to do a seed. I'm not sure how to best do that, though.

CPRM? No, they'll never let us use that for anything useful.

I don't think we can use an extra track, either -- most VMs (which need extra persistent entropy the most) won't support it, and live-CD developers would need to ship a customized CD-burning tool for each platform their users might download the CD with in order to create the CDs on bare metal.

It's easiest to create a 'personalized CD' by clobbering a designated 2048-byte sector of the ISO with random bits after downloading it, and interpreting the all-zero value in the original (as-downloaded) ISO as an instruction to extract entropy from the host system's hardware.

comment:4 Changed 9 years ago by nickm

That does imply the existence of a cross-platform customized ISO-clobbering tool. Possibly worthwhile, though, and probably much easier to write portably than a plugin for every CD-creation scripting tool.

comment:5 Changed 9 years ago by cypherpunks

Just to get the comment down, this will be useful in some environments. It also could make things worse. We introduced guards as a trade-off, but it can become a different trade-off specifically in environments where liveCDs matter most. The most obvious one is that the liveCD will now have something persistent that ties it to a signature of network behavior. Without guards, someone who uses a livecd at various cybercafes is not as easily linkable to behavior. With guards if you are grabbed with that particular liveCD and the adversary (e.g., from running middleman nodes and hostile or observed destinations) associates that guard set (hence that liveCD) with specific past behavior of interest. The only point is to note that having guards at all burned into the liveCD. It should be easy to think of lots of other threat scenarios, but I'd have to think about how likely/dangerous they are to say anything reasonable about tradeoffs. Right now my point is just: adding guards is not necessarily a good thing.

One thing to help at least specifically for the above scenario would be to add a pin/password to be typed at runtime that, when fed into the 'guard generator' is reasonably likely to take you to an adequate amount of the guard space. (Shades of Janus/LPWA/proxymate.) This has the advantage of making it easy to change gaurds or keep them as needed. It has the disadvantage of one more thing for users to remember or store and rubberhose cryptanalysis vulnerability etc. It might also be useful to glance at "Temporarily hidden bit commitment and lottery applications" to think about the shape of the guard space and the potential for various spatial attacks on this idea.
(Hey my first tracticket comment. Wait oh no I can't get sucked in to even one more thing. -Paul (Nick knew it was me anyway.))

comment:6 Changed 9 years ago by anonym

Cc: anonym@… added

comment:7 Changed 7 years ago by nickm

Keywords: tor-client added

comment:8 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:9 in reply to:  2 Changed 7 years ago by proper

Replying to nickm:

Hm. An extra track on the livecd, full of random bits, would be a great way to do a seed.

I guess some people will use it to store encrypted data to have Plausible Deniability [1] [2] [3] An adversary could claim that it contains encrypted data.

Not saying this is bad. Just something to consider.

[1] http://www.truecrypt.org/docs/?s=plausible-deniability
[2] http://www.cypherpunks.ca/otr/
[3] https://en.wikipedia.org/wiki/Plausible_deniability

comment:10 Changed 7 years ago by proper

Suppose that the livecd gathers a set of system hardware information (MAC address, PCI stuff, etc), and hashes it into a "Guard Seed".

When they want to keep supporting virtual machines, they need something else for that use case. (Most) virtual machines share system hardware information, except virtual MAC and machine id.

One thing to help at least specifically for the above scenario would be to add a pin/password to be typed at runtime that, when fed into the 'guard generator' is reasonably likely to take you to an adequate amount of the guard space.

This sounds nice. Adds most flexibility.

It has the disadvantage of one more thing for users to remember

If it gets hashed, couldn't they use the same password they are using for encryption as well?

comment:11 in reply to:  1 Changed 6 years ago by rransom

Replying to rransom:

One (approximate) solution is to pick guard nodes based on the first N nodes sorted by H(Seed|NodeID). This doesn't do weighting correctly, though.

We can do weighting by computing H(GuardID | 0), H(GuardID | 1), ..., H(GuardID | GuardWeight - 1) for each guard, and then choosing the closest guard to H(Seed | 0), the closest not-yet-chosen guard to H(Seed | 1), and so on.

Further improvements are needed to make GuardIDs seed-dependent, make each guard's GuardID change at pseudo-random times, and possibly make each guard-selection value (the H(Seed | i) above) change at pseudo-random times as well.

‘Simultaneous rational approximation’ of the selection-probability distribution might make the performance of this technique somewhat less horrific.

comment:12 Changed 6 years ago by mk

Cc: mk@… added

comment:13 Changed 6 years ago by intrigeri

Cc: intrigeri@… added

comment:14 Changed 6 years ago by nickm

Keywords: needs-proposal added

comment:15 Changed 6 years ago by rransom

Section 4.2 (‘Encoding a message M as B_M’) of https://eprint.iacr.org/2010/446 might be useful.

comment:16 Changed 2 years ago by nickm

Resolution: wontfix
Severity: Normal
Status: newclosed

not currently a design plan; but fallbacks help some here.

It's more and more apparent that a persistent datadirectory is a really good idea.

Note: See TracTickets for help on using tickets.