Hi Bud, Quick response from Barcelona Airport: you seem to be more paranoid than I am (that's a compliment) :-D
I'll take a closer look at your responses tomorrow or Friday and get back to you. Cheers, Roland Bud P. Bruegger wrote: > Hi Roland, > > another round of discussion after some delay.. > > On Fri, 28 May 2010 12:26:51 +0200 > Roland van Rijswijk <[email protected]> wrote: > >> Hi Bud, >> >> Bud P. Bruegger wrote: >>> Security of a Soft (H) Security Module is indeed intriguing. >> Yes it is :-). In my opinion, it should be as secure as possible in >> software. This means sticking to some simple design and implementation >> rules, such as secure coding guidelines, keeping sensitive data in >> memory and in the clear only as long as it needs to be in order to do >> processing with it. >> >>> 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? >> We strive to make it as hard as possible to snoop sensitive data from >> memory, for instance by varying the memory location where key data is >> stored, by zeroising memory that contained sensitive data and by >> locking sensitive data into non-paged memory to make sure it's not >> swapped out to disk. > > I've given soft tokens quite a bit of thought in the past. All these > methods are probably quite effective, but they protect until the point > where you actually calculate the RSA or similar on the CPU and then the > key gets out in the clear. > > I had written a very rough proof of concept where I avoided that the > key ever comes out in the open. The idea was to find an an equivalence > (an isomorphism..) to another representation space in which to compute > the crypto functions. > > Say normally an RSA key is represented by integers (modulus and exp), > this could be mapped to some other representation, for example one where > every integer is randomly stored by two parts: > > origInt = partA + partB > > Now in memory, you have partA and partB, none of which is the key > itself and one of the two can be a random number... > > Now we have to find an equivalent to the RSA algorithm that works on > partA and partB, obviously without reconstructing origInt... > > In a simplistic example, a multiplication of two integers would map to > something like: > > Say in "normal space" we mulitply the integers: i-1 * i-2 = i-3 > > In isomorphic space that would map to: > > (partA-1, partB-1) *' (partA-2, partB-2) > = > > ((partA-1 * partA-2 + partA-1 * partB-2), > (partB-1 * partA-2 + partB-1 * partB-2)) > > So also the result is a pair of integers and in no case, the actual > original integers (keys) appeared in memory/registers. > > The resulting pair can obviously be mapped back to "normal space". > > Not sure whether it's worth the effort since also this mapping is just > an obfuscation and the recipe to crack it is present in the software > that can be reverse engineered... > > but anyhow, thinking about it is fun ;-) > >>> * Unless we find procedures for guaranteeing un-clonability, the >>> whole thing falls apart >> The procedure above guarantees non-clonability if the PIN or SO PIN >> remains secret. > > Well, this is exactly what I mean. This means, it is a "something you > know", not a "something you have". HSM should implement the "something > you have" portion. This _is_ possible also with a soft implementation, > but it means that the _physical_ deployment must guarantee sole > control. > > What I was saying is that we need to take this into account when > talking about remote access to the (soft) HSM. Physical isolation to > achieve sole control is very different from protection with a PIN. It > is something you have (and other's can't get at), while protection with > a PIN waters it all down to something you know. > > Taking this into mind I believe has a strong impact on the requirements > of the PKCS#11 proxy: If the separation of the connection to the (soft) > HSM is physical, then channel encryption (SSL) and client > authentication (SSL client cert) are maybe not as important? > > In a scenario where access to the HSM is physically restricted, I > frankly don't see advantages. So this means, the most > straight-forward way (maybe some kind of RPC) is as good as anything > more complicated. (Or actually better, since simple things have less > bugs). > > Where really a physical separation isn't possible, then my first > reaction would be why have an HSM (s.th. you have) in the first place > if your usage translates it into s.th. you know? > > But if someone really wants to use it that way, maybe a VPN would be > the solution and the protection of the channel and mutual > authentication wouldn't be a requirement for the PKCS#11 proxy... > >> We are also considering - for a future version - >> replacing the PIN/SO PIN by a USB crypto token. > > That could possible used by the VPN... > > And BTW, in the (near?) future, most hosts will have some kind of > Trusted Platform Module that could possible be used for that purpose.. > > [snip] > >> The only alternative is to use a second factor, such as a crypto >> token, to secure the SoftHSM. It is disputable whether or not that >> makes sense but it is certainly cheaper than purchasing a real HSM. > > I think this makes sense where a single key gives access to a very > large number of keys (where that is necessary). But where I have > doubts is performance. An HSM and also softHSM is very performant in > number of crypto operations per time. A crypto token (smartcard/usb..) > is typically very slow (due to the mini cpu on the chip). To make this > successful, a single authentication (signature of challenge) by the > crypto token should be good for a large number of crypto operation on > the HSM... > >> Keep in mind that a good secure PKCS #11 proxy can not only expose a >> SoftHSM over the network but *any* PKCS #11 compliant token or HSM. So >> it will allow you to turn a PCI card HSM into a network HSM. > > This is great! But I don't think the reasoning above is affected > whether the HSM is soft or hard. I think that once it is on dedicated > hardware (doesn't share neither CPU nor memory), then there is little > difference.. > > I was looking around the web quickly to see what eithernet attached > HSMs offer for protection but didn't find anything in a first quick > look. > > Do I see things so much differently from others? > > -b > -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: [email protected] _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
