> Agreed. Requirement #1: a secure connection between the proxy and the > server (SSL, preferably also support client authentication). > > Roland
Security of a Soft (H) Security Module is indeed intriguing. Here some thoughts on how the network connection needs to be protected (quote above) and also a comment on the design: [from: http://trac.opendnssec.org/wiki/SoftHSM/Design] > Secure data manager: ... > The token key is stored in memory during the time a token is logged > in. To protect it against eavesdropping by snooping the memory of the > SoftHSM v2 it is cloaked using a blob of random data that is used to > XOR the actual key data Hmmm. I'm wondering about the effectiveness of this. In an Soft(h)SM, as opposed ot an HSM, memory is potentially accessible by other, potentially hostile, processes. Thus the need for protection--but is it possible? An XOR is a (very) poor man's encryption. But no matter how good the encryption (why not use that of how it is stored on the file system in the first place), sooner or later it has to be decrypted for processing. More particularly, the keys have to be decrypted before passing them to the crypto library--and that is visible in memory. So my questions: * is the effort worth-while, just for shortening the time of exposure? * if so, why not use a real encryption instead of XOR? Now back to protecting the communications of the pkcs#11 proxy: I think a first step would be to agree on a threat scenario, maybe based on a usage assumption. If you look at a smartcard-based digital signature, it can only be created by whom has * something you have (an unclonable HSM/Smartcard/secure storage device) * something you know (a PIN, password, pass phrase). There are some basic assumptions in this approach, namely: * the legitimate owner of the HSM has sole control (or when lost, revokes the whole thing) * something you know exists only in a private memory (our heads) and is transmitted to the HSM through some protected channel that aren't accessible to anyone/thing else. Obvioulsy, writing your PIN on some post-it, or writing it on some disk (no matter how obfuscated), violates the basic assumptions of this approach.. So what is it that we are doing with an S(not H)SM? * Unless we find procedures for guaranteeing un-clonability, the whole thing falls apart * Since it is an application is using the S(h)SM, the secret (PIN) used cannot really be all that private (it is somewhere on the disk, not in a private head), and surely cannot take the same role it does in a human-smartcard scenario. In a human-smartcard scenario, if the card is lost, unless you also steal the secret (PIN), the card is useless. The lost card is enough to motivate a revocation--the secret only protects exploits in the limited time window from when the HSM/token is lost to when it is revoked. (And on top of this, it expresses user-consent to sign a specific document; something that isn't applicable to automatic signatures by applications.) So in my book, "user PINs" have very little value in the security scenario of S(h)SMs since they are neither private, nor express any consent, nor can effectivley prevent exploits of a compromized HSM. Instead, the security of an S(h)SM depends on the degree in which we can achieve "sole control" of the S(h)SM by the application that is supposed to used it--no matter whether it is used locally or remotely. I believe we're getting very physical when we talk of sole control; the only way to getting sole control to a public network resource is via a trusted HSM owned by the user and verified e.g. via TLS client cert auth (as you suggested). But if applications need their own HSM, the S(h)SM idea is really mute anyhow.. I think it is much more realistic to think that sole control comes through exclusive physical access. I imagine for example, that the S(h)SM is a host in a (pad)locked case with the only normal way of access exposes the PKCS#11 functionality. Whoever wants to "tamper" with the security device (e.g. legitimate upgrade and security fixes of the O.S.) needs privilidged access (the key to the pad-lock that is locked away in a safe) that is only possible when authorized, controlled (at least 2 persons), logged, and audited.. Sole control of remote access comes from sole control of the channel to talk to the S(h)SM, a separate network (subnet), if possible through a separate NIC, definitely no routing from the outside world. This is not an S(h)SM somewhere in the cloud, but a S(h)SM in a tightly controlled physical/operational environment. The alternative in my mind is only an HSM (smartcard) to grant secure access to an S(h)SM--an approach which seems to beats the purpose. > But first we need a good list of requirements. Maybe you want to > start on that work? We can assist you more when we have SoftHSM v2. > > // Rickard Well, I hope this is a useful contribution to defining the requirements.. best cheers -b _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
