Thoth • August 13, 2016 6:52 PM

@Moderator, @Bruce Schneier
@Rick is waiting for your (@Bruce Schneier) AMA answers regarding ‘hardening’of his Windows 10 work laptop. Can you get his attention for this.

@Rick, why don’t you email him directly 🙂 ? Also, you stated that you are self-employed and this the Win 10 laptop is for your business purposes.

As I have mentioned, access personal stuff on a personal network and computer and access office stuff on an office network and office computer. I have two networks at home with one for office-only (2 routers) and one for home-only if that would be useful for you to copy.

Since you are asking how not to leak personal information and by that I am guessing you do not want to leak work information since it’s a self-employed business, using VPN, FDE, pretty much covered all corners. You can only get as much security out of the OS that provides the basis for security and Windows especially Win 10 is notorious for leaking users information. There is nothing much that can be done due to the nature of the OS. One method would be to use high assurance Data Diode but that is too troublesome and you are better off without it. We are back to square one all over again 🙁 .

If you are really paranoid, you are better off configuring office network to disable all wireless and only accept LAN and then blacklist ALL sites and protocols and slowly whitelist only protocols and sites you need. The reason is if Win 10 has backdoors to bypass your hardening selections (including modifying registry values), if your network routers do DPI and block all the unwanted sites and protocols, what can a Windows trying to exflitrate information do when it hits a stroct firewall and DPI engine. The management terminal for the network firewalls should be done on a non-Windows computer in case backdoors and malwares on Windows computers decide to play with your network protection console.

To summarise, the answer is not how secure you can secure Windows 10 but it is how much you can use the environment to lock Windows 10 down (i.e. network filtering on routers). This is an adaptation of @Clive Robinson’s Prison model where the Windows 10 is the leaky traitorous CPU and how to imprison the CPU and prevent leakage.

Thoth • August 13, 2016 8:50 PM

@Nick P

re: Apple HSM and Matt Green

I heard someone implicitly summoning me via my HSM connected doorbell 😀 .

“My studies on HSM’s showed many could import or export private keys. This is especially useful for backup/recovery purposes. This also means the keys could be shared with parties doing surveillance. If that’s true, how do you know your password only went to a HSM if encrypted with those keys?”

If you could name a HSM that could export private keys and also whether they are in FIPS mode. FIPS 140-2 Level 3 mode prevents insecure exports of private keys and other keying material. For what I know, Thales and Safenet don’t simply export keys. They use their own crypto tokens to store keymats when transferring between HSMs and their own security domain KEKs to wrap them as necessary and usually they will allow M/N secret sharing export and recomposition. Safenet uses some huge PED device to load the rypto token key shares while Thales uses smart cards. Thales does allow manual secret share export and import via entering wrapped key shares in hexadecimals for those of you who are paranoid and prefer the paper method. The paper method is used usually for the payment application where it requires more security to transport highly sensitive EMV payment LMK keymats used for your credit card transactions and across ZMK wrapped key shares. Good old days of the thousands of US dollars worth of crypto-calculator whose only function is help you to view the shared LMK shards and copy them on paper before you drill a hole into the IC chip of the smart card containing the wrapped LMK and then do paper transport as per the required standards procedure for EMV key transport security as per using the EMV payment application on the Thales HSM and still used till these days.

So for famous HSM suppliers with FIPS 140-2 Level 3 HSMs (FIPS 3), if the company enables Strict FIPS mode, good luck with exporting the private keys. You CANNOT export the keys thus that’s why it’s called a Hardware Security Module for a reason. You can only do a security domain transfer and even if you can view the wrapped key shares via the HSM’s security domain keys, it would not benefit anyone either. Thus, for a properly vetted and certified FIPS 3 HSM operating in Strict FIPS mode (this is a Thales term for strict FIPS 140-2 Level 3 mode), you cannot do whatever password export you mentioned. That option simply doesn’t exist in FIPS 3 certified HSMs with Strict FIPS enabled. You are left with security domain protected paper key share transport (Thales HSMs) or token transport (Thales and Safenet HSMs).

The only concern being whether the HSMs security domain keys are manipulated by The Powers That Be. If the worry and threat model is vs. The Powers That Be, then smartcards, HSMs … almost nothing can be used. We would be frozen in place by fear as we start to suspect which IC manufacturer has been compelled. That means we should assume ALL ICs as untrusted and that would put both Prison and Castle model useless as we are back to “do not say anything if you want it a secret” or “only dead people speaks the truth”. Even paper keys would be useless for who knows hidden cameras and surveillance apparatus might be everywhere.

Also noting that FIPS 3 certified HSMs must operate in strict security conditions and even a single byte of change in the firmware or even a change in hardware even as harmless as replacing a screen or button that have not been used in the certification would immediately invalidate the FIPS 3 certification on the spot and requires re-certifying. Of course the FIPS certification still has many holes left to be desired but those are the technical capabilities that they have dragged like mandating EMSEC which is reserved for FIPS 140-2 Level 4 (highest level) and now for the FIPS 140-3 draft (version 3 of FIPS 140), they are considering pushing EMSEC criteria through to make it more common and pushing up security but the FIPS 140-3 draft is taking to long to manifest.

“HSM’s, esp supporting software, have all kinds of problems. People that work on them tell me about them. They all say they rarely talk publicly about it due to threat of losing job or getting sued. I’m not posting further on this point except to say it’s a matter of faith until proven with rigorous evaluation that only a few have. Like any security claim.”

SO far I have not seen or heard nor experienced anything with HSM’s supporting software having serious enough problems to be concerned a security concern or security weakness as of yet from the Thales HSM side which I frequently work with. I also rarely heard about Safenet side but maybe because I use Thales HSMs as my main stay.

“”This rules out both malicious insiders and government access”

No it doesn’t. See “rather than trusting Apple” above. The government’s own standards, EAL6-7 and NIPSOM, show in theory plus practice with prior evaluations that it takes a lot to stop all the threats most of the time. Not everything or always, just mostly. There’s no way these money-grubbing companies did all that. They certainly didn’t claim it in evaluation. I also didn’t see any Snowden slides where the U.S. government griped about targets using HSM’s despite a bunch of them doing so. That might be due to pervasive insecurity where they just hit something else. Yet, I’m still concerned given most HSM’s come from defense contractors that only care about the bottom line in jurisdictions known to bribe or secretly compel parties for surveillance boosts. Assume they have your stuff if you solely use a HSM to protect it.”

I am also not convinced if HSMs prevents Government access but HSMs are capable of preventing malicious insiders as long as the administrative quorums needed for colluding is high enough where a single malicious insider cannot do anything unless he/she colludes with all other key custodians to a point where the administrative quorum has been reached and enough to authenticate the command to the HSM to perform actions like wiping the HSM or transferring keys to a HSM the attacker owns.

Noting that Thales HSMs have “legal restrictions” in the form of their licenses for feature activation in the name of crypto export control from the UK and that you do not get all the security features from day 1 until the signed licenses issued by Thales arrives and is loaded into the HSM(s). One such feature is a rather dubious option selection between everyone else (Restricted Mode) and some European/American mode (Unrestricted Mode) when running the Secure Execution Engine which allows you to load your personally crafted applets you want the HSM to run in the security confines of the HSM’s SEE engine besides the usual Key Management engine. Before you can load your specialized blob into the SEE engine for Thales HSM, you need to show your codes to Thales and they have to approve and sign your codes that will produce a special “warrant” (HSM certificate) that you load the signed code’s warrant with the code blob and also select the Restricted/Unrestricted mode base on the country you are operating in. If Thales HSMs are used plainly for the basic Key Management, it’s all fine and good with Strict FIPS enabled but once you have to write codes to load into HSM for Secure Execution codes … I would like readers here to know that your codes are scrutinized by Thales before they can run it inside the SEE of a Thales HSM. If you are simply running a financial business and you want to run SEE codes (the proper name is called CodeSafe codes according to the Thales SEE CodeSafe branding), Thales supports financial businesses running CodeSafe (i.e EMV crypto codes, EMV PIN crypto … ). If you are using Thales HSM because you are a Government agency needing to secure some critical codes in Thales CodeSafe engine or you are some cryoto-activist or maybe have an agenda not aligned to US/USA/Allied-friendly, you better think quadruple times before you want to use CodeSafe. One example are running Bitcoin hot wallets for Bitcoin Exchanges inside Codesafe which I am strongly against due to the fact Governments have varying views on Bitcoin and some view Bitcoin as Anti-Government activities and thus are hell bent on wiping it out so think quadruple times before using these special CodeSafe features.

For Thales guys who maybe lurking here which you know who you are, sorry to push in the spoiler but I don’t trust your CodeSafe even after helping you guys service CodeSafe. It just ain’t meeting my “Trustworthy” mark 🙂 .

I will point out how to operate a HSM and also run your SEE codes without trusting the HSM’s SEE engine but use them for Key Management on another LONG POST. I know I am writing too much (probably even for my own good).

“You see, the HSMs Apple uses are programmable. ”

I think I just bunched that together above. No I don’t trust a programmable HSM either. Read above. The KM is fine but the SEE is not.

Just a reminder that in FIPS-3 mode, all your programmable SEE codes cannot be used because FIPS-3 mode requires a clean environment and SEE codes are considered uncertified and thus unfit for running FIPS-3 mode.

WWWWAAAAAIIIITTTT … that means Appple wasn’t using HSMs in FIPS-3 mode because they could run their custom codes which means without the security of FIPS-3 … OK … now you may export the private keys without restriction 😀 . No FIPS-3 means weakened key export security. Hehehehe ….

“”Note that on HSMs like the one Apple is using, the code signing keys live on a special set of admin smartcards.””

This part maybe misinterpreted with a very high degree of certainty in my opinion. The admin cardsets are not storing any keys whether it is for Safenet, Thales or whatsoever HSMs. How it works is, to approve X operation, you need the admins (with enough quorum) to present their crypto tokens (USB crypto token for Safenet and smartcards for Thales and AEP Keyper) in front of the HSM via it’s USB token or smart card slot on the face of the HSM hardware. The admin keysets are used to sign operations like loading custom codes or exporting keys and so on. If you physically destroy enough quorum of the admin cardsets, you suddenly don’t have enough admins to form back the proper quorum of admins needed to approve X operations that requires that particular admin cardset to authorize those operations (noting that every Key Blob Object has a Crypto ACL ruleset governing how the key can be used, how many times it can be used, under what conditions it can be used and by which admin cardsets assuming many admin cardsets and under how big of a admin cardset quorum).

Just to prevent confusion, the cardset controlling the signing key is not called an admin cardset but an operator cardset. Because if you destroy the admin cardset (with enough destroyed quorums), you cannot operate the HSM when you need to. The admin cardset would only have rights to administrate generic HSM functions (more like a Sysadmin) whereas the operator cardset has the fine grain ability to control the crypto keys (thus the name operator cardset – a.k.a Crypto Operator). The problem with destroying the admin cardset so prevents updating the SEE engine codes but would also make administrating the HSM impossible as well so I am thinking they created a Code Signing Operator Set to govern and create the Code Signing Key and then once done, simply destroy the Code Signing Operator Set would pose a problem with what to do with the lingering Code Signing key still sitting in the HSM (presumably in unlocked mode for free and easy key usage) and the what-ifs for using the Code Signing Key assuming you need to sign codes with the same key and also the key revocation problem where without the Code Signing operator cards, there is no known way to revoke the key because the actual HSM Admins are usually designed to be only concerned with generate administrative procedures of the generic HSM functions (loading CodeSafe codes, migrating HSM environment, reboot of HSM, creating new HSM environment …etc…) and most HSMs have segregation of duty built into their architecture where the HSM Admins cannot interfere with the keys protected under a specific set of Operators. This ends up in a Chicken-and-Egg problem with that kind of simplistic thought that shredding a HSM’s operator cardset physically would mean no one can gain access as now the owners cannot gain access or use the key either. You need the original Operator to transfer the control of the keys to another Operator and the HSM Admins have no say over transferring of rights of keys (at least from Thales HSMs point of view).

“We run the cards through a blender.”

The most important part of a smart card is the metal contact. Just cut across thhe metal contact in an asterisk shape and you have rendered the 2mm x 3mm IC useless. View an actual smart card chip I personally opened below (still have the epoxy on it).

It’s too much to post in one pot so I will break it down here. HSMs are secure against insiders for a reason (tamper resistance and administrative quorums). They may not be secure against Governments as we all know and it requires a setup that shares the security load (i.e. Prison model). The smart cards’ chips are very tiny and my recommendation of destruction would make it very very hard to recover even for HSAs if you did view the image posted below on how small that chip is. The importance of enabling FIPS-3 mode and not go about destroying operator and administrative cardsets just to prevent the HSAs from entering. It inconveniences oneself but does not guarantee prevention of HSA entry via backdoored HSMs (if it exists).

I will post again later (as I am busy now) on how to use a smart card as a tamper resistant SEE engine which you have control over the codes and execution while still use a HSM for Key Management and backup of wrapped keys without needing to compromise either. A smart card would be very slow on execution of security codes but you can load balance them on a USB hub with USB smart card dongles to accelerate their speed for your custom codes which you have MORE CONTROL over (vs. a HSM’s SEE where the codes must be vetted by HSM providers) and then use HSM to do backup securely.

Be back in a moment…..

Link: http://imgur.com/a/l3al0

Thoth • August 13, 2016 10:13 PM

@Nick P
Answering while travelling to my destination on smartphone. Short answer for is the iCloud scheme secure is YES it is secure if your device passcode is strong.

How it works after reading the Blackhat slides is passcode derived key (MKEK) wraps a backup escrow (KEK) which the KEK wraps Key Object Blobs. To access the escrow KEK, you need the passcode and bruteforce is the problem which is solved by a securely long password. The escrow is NOT generated by the HSM but by the iPhone SEP. So the HSM cannot access the escrow unless bruteforce the password.

Are users cloud keychain secure from academic perspective in short. YES of strpng password protects the SEP made KEK.

HSM from slides only bother with voting to allow fetching and changing of password try counter and has nothing to do with unwrapping or wrapping the Key Object Blobs whatsoever. In strict sense, the user’s key escrow is only accessible from the user who knows the passcode and nothing more.

Since the escrow cannot be unwrapped by HSM, there is nothing to log down or unwrap assong unwrap is done on endpoint iDevice SEP processor.

Thoth • August 14, 2016 8:10 PM

@Gerard van Vooren

“Are you using OpenBSD? If so, what’s your opinion about its usability from a desktop/laptop “power user” perspective? What are its pros and cons? Me, I am using Linux distros.”

I am only experimenting OpenBSD within a VM and I think @r covered pretty much and there’s the usual open source GUI Windows Manager (i.e. XFCE and all that).

My threat model is to not do everything on OpenBSD or on one platform. Ubuntu, LinuxMint and Windows 7 and older versions suffice for day to day communication and casual browsing when secrecy and security threat model are for the lower end. Anything higher on my threat model list would default to Live CD based TAILS and if necessary bring in OpenBSD.

Pros would definitely be tighter security and cons would be the lack of software packages that you may expect and enjoy on Linux.

As I have mentioned many times, I only place the most sensitive security logic in the bunch of smart cards I own and that includes PGP Key Management inside smart cards. If you noticed recently in the previous Squid post, I mentioned on using smart cards to do PGP Key Management for my PGP keys and if security necessitates, it would be Linux + Smart Cards which can be used to encrypt file and emails.

I consider online browsing pretty much a gone case as there are basically three main browser engine manufacturer namely Google (Chrome/Chromium – although it’s a community effort), Microsoft and Mozilla. Web browsing is pretty much gone case even if you use Tor Bundle or what not. Who knows what bugs or backdoors are inside these browsers with bloated features and codebases.

What I feel that is requires protection would be communication and cold storage (File Encryption). This is where the use of PGP keys comes in and the smart cards with PGP capability comes into play.

So back to the main question. Use OpenBSD only for generating keys, key management and key imports (that’s it’s whole use in my threat model) into my PGP smart cards. Other than that they are in cold storage. The rest are done on Linux (Ubuntu and LinuxMint) and Windows 7 depending on what I need to do (communicating to clients or personal) since they are much more convenient with more software packages than OpenBSD.

I consider my browsing not secret to state actors or even those huge companies like Google. How I create email messages that require PGP encryption (how I communicate with @Nick P) would be to open a text editor (never to edit your email in a web browser) and then type my message, PGP sign and encrypt (smart card inside card reader slot) and then discard the plaintext as needed or if I need to keep a copy, I just encrypt it and store it away. They revolve around having the smart card protected keys.

Thoth • August 14, 2016 8:34 PM

@Wael

Either would work 🙂 .

Thoth • August 15, 2016 3:10 AM

@Figureitout, Markus Ottela, djb crypto et. al.

I have created a 8/16-bit capable ChaCha20 implementation following RFC-7539 guidance instead of the original DJB’s version in Java (and also another port for JavaCard) which bypasses the 32-bit Integer which ChaCha20 uses and instead just using 8-bit operations (8-bit byte arrays).

Anyone wanting to reference the ChaCha20 implementation if they have 8/16-bit embedded projects may freely take a look at it’s codes before attempting your own.

I will release 2 Github repositories (both essentially implementing the same 8-bit math library for 32-bit operations I created) but one is styled in a JavaCard context and the other in a normal desktop/server context (normal JVM). Both are still experimental but for the cipher system, it has passed the basic RFC-7539 KAT test vector.

The ChaCha20 implementation leverages on RFC-7539 specifications using 256-bit key, 96-bit nonce and 32-bit counter instead of DJB’s 256-bit key, 64-bit nonce and 64-bit counter. This means that the RFC version can only encrypt 256 GB (estimated according to the RFC authors) of data before at the entire set of key, nonce and counter must be changed whereas DJB’s original implementation (non-RFC) has a bigger data size due to 64-bit counter but a smaller nonce of 64-bit.

This project is an attempt to try and add ChaCha20 as one of the default ciphers for my other project namely GroggyBox so that on the smart card side, users can have an option to select ChaCha20 (RFC7539) besides having the standard hardware AES.

To my knowledge, it is highly ill advised to implement your own cipher for smart cards due to constrain space but as @Clive Robinson have mentioned, AES has too much problems and this is to my knowledge one of the few or even the first initial effort to push ChaCha20 onto a smartcard system (albeit risks) and hopefully to have it stabilize and make ChaCha20 more mainstream even in the embedded space (JavaCard and other embedded security systems running 8/16-bit CPUs) besides the desktop and server space.

The jcChaCha20 is a JavaCard ChaCha20 library specifically optimized for JavaCard smartcards and the jChaCha20 can be used for JavaCard, desktop and servers but is better for desktop and server JVM usage although I should point out that there are already other ChaCha20 variants running at full speed (or even accelerated) in Java because they use 32-bit word sizes whereas my implementation uses 4 pieces of 8-bit word sizes (shrinking the 32-bit maths to 8-bit maths) thus it would be very much slower and less efficient than other known Java ChaCha20 libraries.

When using the cryptographic function, it is only capable of processing 64-byte input (as per the stream cipher design). If you want to process more than 64-byte data input, you need to manually increment the counter after every 64-byte data you input and call the encryption or decryption function again and again after every 64-byte of data passed into it with manual effort to process an arbitrary stream of input. Once you have finish using the counter assuming you start off the counter with 0x00000000 and end with 0xFFFFFFFF, you need to re-key another nonce, counter and key manually.

Because the library does not implement standard JCE cipher and key classes, it is thus not bounded by export control that the JCE attempts to make Java users conform (to US/UK’s export control bullying).

Links:
– https://tools.ietf.org/html/rfc7539 (RFC document)
– https://github.com/thotheolh/jChaCha20 (JVM/Desktop/Server/J2SE)
– https://github.com/thotheolh/jcChaCha20 (JCVM/JavaCard 2.2.2 and above)

Thoth • August 15, 2016 10:02 AM

@ianf

re: Open YOLO

Dashlane partnering with Google. Designed behind closed doors by closed source password manager. Backdoor alerts sounding everywhere 🙂 .

Anyone going to use it is literally YOLO-ing their own personal privacy and security. It’s about time people should stop buying into these fake security hype.

Thoth • August 15, 2016 7:10 PM

@Nick P

Google’s Fuchsia using it’s own Magenta “Mini-Kernel” with supposedly 97% of drivers and services loaded into userspace. Sounds like a microkernel of sorts but with more bloat and thus but I doubt it was built with much security property in mind. Yet another fail for mobile security and mobile OSes … Oh … I forget security doesn’t exist on mobiles … just security theater when considering the current state and history of Android and now Fuchsia.

Links:
– http://www.theregister.co.uk/2016/08/15/googles_new_os_could_replace_android/
– https://fuchsia.googlesource.com?format=HTML
– https://fuchsia.googlesource.com/magenta/+/master

Thoth • August 16, 2016 5:41 AM

@Curious

It’s not really about the word written by the tech journalist reporting on the issue in the clumsy way. FHE was always an odd science.

Thoth • August 18, 2016 4:59 PM

@Clive Robinson, r
My method I have always done is simply send or attach fhe PGP public key and then self-sign it in the first email message. For code repos, to put the public key inside the code repo, do my own SHA256 hash of key and create a hashes.txt file to write all the source code hashes, public key hashes and other file hashes in SHA256 and then sign the hashes.txt. This prevent the need to “look for the public key” and mitigates the problem of the other party finds a duplicate DWORD hash or colliding short ID hash by simply spoonfeeding the key right in front of them so they have no excuses of “finding the wrong key”.