I love the nitrokey stuff. If you want some practical examples, see the articles I wrote on the different models: https://raymii.org/s/tags/nitrokey.html - both HSM, Pro, start (which is a gnuk stick).
The support of codeweavers is very good and fast as well, the two times I had to contact them.
The bottle system is amazing. It allows you to have multiple wine environments with different Windows versions seperated, so not just one Wine for all. Office 2003 runs on Windows XP, 2013 on a Vista env.
The bottles can be exported to RPM or DEB or shell installer for easy deployment as well. Plus the easy online database with appliations and profiles makes Crossover, for me at least, have a big advantage over bare Wine.
As far as I know, the "bottle" system is available in standard wine too (as wine prefixes), Codeweavers just provides a very fancy wrapper for the system and tools for managing the bottles. And that is definitely very handy if you want things to "just work" and dont want to fuss with prefixes yourself.
PlayOnLinux is a community application using WINE and with CrossOver you get full time employees working on the latest issues on Wine and first releasing their fixes into the application.
They then turn the code over to WINE downstream. So when you help CrossOver you financially help WINE and a person who will help you with your problem within 24 hours. Also CrossOver gives you their bottle system and a great website to get your stuff working.
The government orders the ISPs to cut the connections - how they ISPs actually do it is up to them - whether they power down the routers or simply enable firewall rules.
In small countries, especially in Africa, there might be only one or two Internet exit points for the entire country. It's not like the US where there can be a dozen or two Internet traffic exit points.
I'm behind https://cipherli.st, together with some friends. IMHO there is no reason not to have HTTPS everywhere, especially now Let's Encrypt exists. I did think and discuss a lot with people on how 'strong' the page is, and if we might want to change that. The page is targeted at sysadmins who I expect to do at least some research before bluntly copy-pasting config files off somewhere, there are enough warnings on the page.
I'm not normally someone who complains about other people's designs but is there a chance you could fade the watermark a lot more? It's still quite bold and immensely distracting which makes it harder to read the content (or at least it does me, but being dyslexic I do have to concentrate harder with reading blocks of text anyway).
That aside, your site looks at valuable resource. Thank you for publishing it.
> IMHO there is no reason not to have HTTPS everywhere, especially now Let's Encrypt exists
I don't want to disagree with you but I do. I most certainly agree that HTTPS must be everywhere and it's easier than ever before. Where I disagree comes with less experienced developers. I can write a quick PHP / Rails / Node / whatever web server to show some website real fast, deploy by uploading it to a shared hosting package or something fancier like elastic beanstalk, and it's done and up there. Yes it's on HTTP but it's so easy. Now you want to add HTTPS to it? It's not easy. Let's Encrypt makes some aspects of it easier but until the amount of fiction is similar to the process of deploying HTTP you'll never see HTTPS ubiquity in my opinion.
Run the python process on a different port and let Caddy act as a proxy, forwarding requests from the original port to it. As described in the second (proxy) link.
i use let's encrypt on google app engine... it took less than 5 minutes. google could very easily automate it for everyone, but that removes the direct verification between domain owners and certificate authorities.
granted, you're already giving up this control when you host with any 3rd party, but the CAs are being reckless if they encourage it.
Author here, do note that device access and access to all previously setup passwords and PINs is required for this to work. It still beats the purpose of the HSM though. The article explains this a bit more in the #Rationale section. Happy to answer questions or comments.
From #Rationale (concerning the backup option that most commercial HSMs allow):
>> I do am of the opinion that HSM's should not offer this option (getting access to the private key).
It boils down to your opinion then. Within the industry "HSM" is pretty much synonimous of compliance to FIPS 140, which allows key extraction even at its highest level (Level 4), provided that the risk is mitigated appropriately (E.g. by means of a split secret policy and more in general by means of all the security measures that go beyond the technologic ones provided by the HSM itself).
You are free to keep your opinion but the statement that such possibility "still beats the purpose of the HSM though" is not shared by many people.
Also (again concerning the backups):
>> Since it requires so many steps and so much access, I don't think this is a huge risk, but a rather nice convinience.
No, it is not a convenience. It is a manner to mitigate the risk of denial of service one may cause by purposedly destroying or stealing your HSM.
>> I've seen multiple big-name HSM's where their support was able to decrypt the key and transfer it to another HSM model, but since I've signed an NDA I cannot tell which ones that were.
I challenge this statement: I deal with most big-name HSMs (and there are not that many) and none of them can do this.
I do know because that is a risk we explicitly check for when evaluating one.
In certain cases you may manipulate their API to extract some keys if they were generated internally in a certain way, but that is a known, public problem in the industry.
> You are free to keep your opinion but the statement that such possibility "still beats the purpose of the HSM though" is not shared by many people.
I'm aware of the FIPS standard, therefore I worded the piece as my opinion. I think it's better to be able to rotate the keys then to restore to the same/other device. Since extraction might lead to decryption. I do also know that software-wise that is an inconvinience and in some cases not possible. Bur still, a device that protects private keys should not give them up. As you say, my opinion.
> No, it is not a convenience. It is a manner to mitigate the risk of denial of service one may cause by purposedly destroying or stealing your HSM.
Stealing should be protected by the tamper-protection, thus causing a wipe of the device. In that case you might have a bigger problem, someone has access to your datacenter and racks. In that case a backup is very welcome. (I do find it a hard problem where the two sides, no backup, a backup, both are equally important.
> I challenge this statement: I deal with most big-name HSMs (and there are not that many) and none of them can do this. I do know because that is a risk we explicitly check for when evaluating one.
We've had a situation were two different revisions of the same device were not able to load a wrapped key. Support flew in and told us they could fix in in a new firmware in three months, no guarantees. We installed screen recorders and a keylogger, since they were on our production env (audit logging). They did, with undocumented commands, export the key from the device in an unencrypted format and loaded it into the other model so that we could continue our operation. Reviewing the recording and the logs showed that the commands did also work on other HSM's we had. I'm still under NDA so I cannot talk about which brand or model specific.
> They did, with undocumented commands, export the key from the device in an unencrypted format and loaded it into the other model so that we could continue our operation.
NDA or not, that company should be put out of business. Essentially they've backdoored that HSM.
Assuming it is true this is far bigger news than the article you wrote.
I think your article is unfairly characterizing the Nitrokey HSM and the underlying SmartCardHSM applet as "defeated". Your reasoning feels like a tautology to me. Of course having all the cryptographic keys used to protect a secret will enable you access the secret.
A legitimate attack would allow access to the secret without first having all the necessary cryptographic keys protecting the secret.
As you describe it any HSM that allows for the transfer of keys between devices is "defeated" by design. An HSM without any ability to trasnfer keys would be much less suitable for any application where disaster recovery is required (which, to my mind, is most real-world applications).
We selected the Nitrokey HSM last year for a Customer's firmware signing project specifically to have this functionality. It was difficult and/or more expensive to obtain this functionality from the "big name" HSM vendors. With a product lifecycle of 20 years, my Customer required being able to, in a worst-case scenario, recover the plaintext of the signing keys to move to a new HSM platform. The "big name" players were quick to say that we could transfer keys between their hardware platforms (because they have a "behind the scenes" root of trust), but extracting keys to move to another platform was met with resistance.
Secure procedures for creating and handling the PINs and DKEKs can mitigate every part of the 'attack' you describe. I feel much more confident in handling those procedures myself versus relying on a root of trust held by a "big name" HSM vendor. I consider this a major advantage of the SmartCardHSM platform.
You mention that SmartCard-HSM/Nitrokey HSM are open source, which to me seems a bit disingenuous, since the most important part, the applet itself, is closed source AFAIK. You can't get the source that you can compile to a .cap file and upload it to your own blank java card.
