On Sunday 21 Jul 2013 23:20:40 Robert Hailey wrote: > > I'm not 100% sure how this might work, but having opennet require a security > device might be publicly acceptable, and might also serve as the monetary > disincentive to an opennet sybil attack. > > Without looking too much into it, I supporting a smartcard interface from > java (across many platforms) would be problematic. A one-time-password (OTP) > solution might work, though. > > One such device I have experience with: > http://www.yubico.com/products/yubikey-hardware/yubikey/ > > Such an onboarding user story might look like this: > (1) a new user browses the freenet site and finds out that freenet generally > requires a yubikey > (2) they install freenet, but it doesn't work (or works poorly), and also > says something about needing a yubikey > (3) we lose a bunch of lookie-loos with an interest in freenet that is > <$15+time, but security-interested folks might be further interested in > getting "the security device that freenet requires" anyway > (4) so those that remain order a yubikey (min quantity 1), > (5) a few days later, the device arrives (quick-ish, as singletons are mailed > in an envelope) > (6) they go back to freenet, click in the "yubikey field" and mash the > "button" (it's actually a capacitance sensor, I think) > (7) through some mechanism not visible to the user, the OTP is verified and > an opennet certificate is issued > > Maybe at some semi-obvious state change (like a machine reboot, or the > yubikey being used on another N machines?) or period (monthly), the field > would popup again to make it seem important & remind the user that a yubikey > is needed to spread freenet. > > The generated OTP has a prefix that uniquely identifies it (sorta like a > serial number), and can only be verified *once* (it is then, by definition, > stale). > > If we use the default "short-press" identity that comes with the key, then we > would be implicitly trusting YubiCo to not hand out gobs of identities to an > attacker (i.e. without paying). In fact, that's the only option really... we > could not use a custom identity, b/c either we would have to supply/program > the keys or we'd be right back to a sybil attack (they just put the OTP algo > in software). > > The implementation of step #7 really depends on wether or not we trust our > seed nodes, and wether or not making a conventional http/https connection is > acceptable. NB: we could always bundle a public key in with freenet to make > it "safe" to hand off an encrypted OTP for delivery back to the mothership... > I mean, "central server".
I don't see why this would help.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
