https://scholar.google.com/scholar?cluster=92037504584829650...

This paper explains how an attacker can efficiently factor 184 distinct RSA keys out of more than two million 1024-bit RSA keys downloaded from Taiwan's national "Citizen Digital Certificate" database.

These keys were generated by government-issued smart cards that have built-in hardware random-number generators and that are advertised as having passed FIPS 140-2 Level 2 certification. These 184 keys include 103 keys that share primes and that are efficiently factored by a batch-GCD computation. This is the same type of computation that was used last year by two independent teams (USENIX Security 2012: Heninger, Durumeric, Wustrow, Halderman; Crypto 2012: Lenstra, Hughes, Augier, Bos, Kleinjung, Wachter) to factor tens of thousands of cryptographic keys on the Internet.

I mean that's a seriously big advance over anything I imagined a govt capable of. Estonia was the only other place I heard even close.

And is 183 out of 2 million so bad? Just sign the next round of certificates with this lot and move on.

So yeah, these things are getting deployed in some places but I'm not too hopeful it will end up being much more than a gimmick. At least I hope not because the next step on the minds of some of these "technical" people is electronic voting and that won't end well...

But since no browser makes it easy to sign anything with a certificate stored on disk (or in a USB stick), this policy has led to serious dependence on ActiveX plugins (and therefore IE and Windows) that everyone has probably heard about.

Now the Koreans are trying to fix that, but since the government is just as boneheaded as ever, the officially mandated "cross-browser" solution is just a Windows binary that installs NPAPI and PPAPI plugins into every browser. Some variants even work on Linux, but only because they're implemented as Java applets.

PKI is cool in theory. In reality, it's hard to implement it in a way that is accessible to the general public.

Not very smart move if you ask me. If you teach users to ignore HTTPS errors, then MITM attack becomes easier because user don't see anything suspicious.

In our case I think we even have our own CA trusted by the browsers so there's no apparent reason for the self-signing.

>If you teach users to ignore HTTPS errors, then MITM attack becomes easier because user don't see anything suspicious.

That's precisely the point I made to the "technical" person and it was ignored...

It's a little unclear to me what the current status is: apparently it's valid for the National (Tax etc) Portal (altinn.no - literal translation: (hand)ineverything.no)). The basic idea was that the Postal service already allow the sending/delivery of registered letters -- so why not just use that for validating the ID. These days mail is largely handled by supermarkets -- and my impression is that the ID check isn't as reliable as it used to be when the postal service operated as a government monopoly.

Anyway, AFAIK, it's still the closest thing we have to working, secure digital ID in Norway.

German ones do something similar since late 2010. The card can be used for online authentication and eletronic signatures (requires certificate that is separately available).

http://en.wikipedia.org/wiki/German_identity_card#Chip

So does Finland (since 2004).

But under 10% of the population has such a card (most people use drivers licence and/or passport as ID), and thus almost no private web services accept it for identification.

(How can you use a completely compromised private key as a root of trust for another certificate, anyway?)

Finally, the U.S. gets a mention.

This is a solved problem in Windows. The sysprep tool wipes out the hostname, security keys, user accounts and a bunch of other things one can configure, so the image initializes properly the first time it's booted.

I am curious if there are similar tools for Linux & Unix that the image builders simply failed to use here, or if this points to an opportunity to build a useful tool.

[1] http://libguestfs.org/virt-sysprep.1.html

[2] http://linux.die.net/man/8/sys-unconfig

https://cloudinit.readthedocs.org/en/latest/

http://libguestfs.org/virt-sysprep.1.html

Still doesn't exist any sane, open automation for that, as far as I know. Maybe we should be happy people use keys at all, never mind if the trust/validation is flawed... (not to mention keys never expire, and can only be revoked via a black-list).

There are still real issues with managing root keys etc -- but with cert support in openssh (client and server) that provides a sane basis for trust management.

For Userify, the service (as opposed to keys, auth, servers and users: the problem) -- I think spending some time on a UI to manage certs/ca for ssh, documenting how to use it for user-keys/certs -- and offering to run a CA per Userify-account (ie: generate/manage the root CA-cert, allowing "instant security" by deploying the Userify-user's CA root cert on servers, and having a service to sign public-keys with that key) could be one very sensible approach.

There might be some added benefit with an "always on"-service, by issuing short-lived user certs (valid for, say 8 hours a la kerberos tickets) -- but for that to be useful, perhaps some work would be needed with forking putty for windows users and/or patching ssh-agent/ssh for nix/OS X users. The basic functionality is there, but the UI/UX is lacking. Note that a user can keep the secret key* for as long as he/she is comfortable -- it's only the signed public cert that needs to be updated (as the previous one expires).

Not sure if that answers your question, but those are some of my thoughts on the matter :-)

[1] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/...

btw, please feel free to become a user ;)

So if a service provides users with "session-tickets" (eg: certs valid for 8 hours, or 5 days etc) -- the servers need not call-back to userify. Authorization (for at least part of use-cases) becomes decentralized. Add an api for extending the validity of a cert (client does a lookup, userify checks policies, and if everything is ok, signs the key for a new validity-period) -- and everything should work very nicely indeed.

For those interested in ssh certs in general, see also:

https://github.com/cloudtools/ssh-ca

As for the userify shim, even though you've answered my question: https://github.com/userify/shim/issues/4 -- you might still want to include a license file, or something along the lines of: http://www.tarsnap.com/legal.html in the readme.

Might also want to have a free/open licensed spec of the api somewhere, so that if someone were to implement a self-hosting, free/open service that could be made api-compatible with userify, there'd be a clear way to do that legally.

I've always been uncomfortable about that. How much boot time entropy can a VM have?

I can think of:

- Hostname conflicts

- SSH key duplication

- Driver issues if the hardware is not the same

Are there more?

This seems like a compelling argument for bootstrapping new instances with configuration management, rather than trying to re-use OS images.

https://www.shodan.io/search?query=hostname%3Alocalhost

Days?! That is a crazy-long deploy time.

Ooops.

I have VM images begin without ssh host keys and have a service dependency on haveged: http://www.issihosts.com/haveged/ and http://security.stackexchange.com/questions/34523/is-it-appr...

http://www.gremwell.com/ssh-mitm-public-key-authentication

You'd still be able to impersonate the server, but that's less useful in the general case unless you can emulate the remote machine convincingly long enough to gather useful information.

Even the thing you link to actually says:

> The algorithm itself does not protect against active MITM attack, but it makes it impossible for MITM attacker to influence the choice of the shared key (and by extension the session ID) by the victims.

Does not protect against active MITM attack. It _does_ keep an attacker from influencing choice of shared key, but an active MITM attack is still in the middle and doesn't need to influence choice of shared key to mount many many kinds of attacks.

The attacker just has to authenticate with the correct signature to each, but if it's an attacker, why would it just pass along the victim's data anyway? The whole point of an MITM is that you can modify data before it hits its target.

Thus, all these machines with duplicate keys are VERY vulnerable to MITM, because anyone with access to one of them has access to the private key.

"there are no tools implementing MITM against an SSH connection authenticated using public-key method ... Being pressed to produce a PoC for this attack, I have attempted to implement it only to discover it is quite impossible and here is why."

http://superuser.com/q/189355/33303

http://serverfault.com/q/170682/80866

http://security.stackexchange.com/q/40050/13510

http://security.stackexchange.com/q/10963/13510

http://unix.stackexchange.com/q/27661/14305

(These are the things you're asked to verify the first time you connect to a new server.)

This is the list of most popular searches: https://www.shodan.io/explore

Userify (cloud ssh key manager) is getting a feature to force re-generation of server-side keys across an entire cluster remotely.

So, FreeBSD and Linux both use hardware RNG's as entropy inputs and mix-in other sources of entropy as well (which hopefully mitigates any loss of available entropy and also adds in other believed-good sources of entropy such as timing, network traffic, etc).

Ubuntu is using a new network-attached source of entropy which is itself constantly reseeded with the network traffic used to access it. (There's some inception joke there somewhere..) Of course, you may not be able to rely on the SSL/TLS connection that you're using to access it, so you might be seeding with an attacker's steady stream of 1's...

Of course, getting access to real hardware entropy in a hypervisored or virtualized cloud server/instance is the second part of the problem.

The third part is to make sure that SSH server and client keys are distributed properly. That's what Userify is for, but it really only helps with the client/user keys.. it doesn't help with server keys. (Yet?)