Schneier on Security

Thoth • August 12, 2016 6:44 PM

@The bear is angry

Possibly the tip of the iceberg for WW 3.

@Rick

The best option if you have to use Windows is downgrade to Windows 7 without all the cumbersome and useless who knows what updates. It's impossible to secure Win 10 since this version is the most intrusive version of Windows ever built. Forget about Win 10 if you really want your privacy and personal security.

If it's used for work. Strictly do not use it for personal browsing or accessing any sorts of personal emails. Use a Linux to browse for personal use and use a USB flash drive to transfer data between them at the very least.

Thoth • August 13, 2016 1:58 AM

@Rick
Since it's a work laptop (assuming supplied by company IT dept, let them do the security).

Anything personal that goes through the work laptop is a gonna so make sure you have a for office storage media and never store personal stuff on it.

To summarize, you need to seggregate work and personal for safety where work stuff don't leak personal details and personal stuff don't leak work details. These are my personal opinions.

To be direct, securing Windows is impossible and it's known to have golden keys and backdoors. Linux, with Linus Torvalds refusing to harden Linux by default, is also another gone case.

@Nick P and I have been banging on getting the secure and private stuff onto dedicated secure hardware and to use OpenBSD and hardened variants of FreeBSD as the single only way forward until a community edition of some security microkernel emerges that is production ready and verified then we can talk Secure OS or at least a tiny chance of privacy. Other than hat all roads are pretty much unviable.

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 :D .

"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 :D . 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 8:52 PM

@Nick P

"Green's misses are so obvious on a few of the issues that I'm going to start reading his claims more carefully from now on if it's not crypto algorithms or protocols he's reviewing."

He missed too much to be desired. I might find time later to read and try to fill in in more details if I still have the energy to do so. Busy busy busy !!!!!

BRB ....

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 13, 2016 10:14 PM

The voting protocol they used are impressive too :) .

Thoth • August 14, 2016 1:44 AM

@r

Write your own smart card applet for security sensitive codes that requires secure execution and execute it from within it's security confines.

You get to control most of the execution and no central authority needed to vet your codes. You own your own environment to a hige extent.

Thoth • August 14, 2016 6:53 AM

@tyr

"The old Chinese tradition of
making everyone responsible for the community
reputation (face) kept a lot of antisocial acts
under the public radar. If you didn't the whole
community turned on you to correct your errors."

Isn't this common in every community and not just the Chinese ?

Thoth • August 14, 2016 8:38 AM

@Nick P
I have mentioned about using HSMs and Smart Cards in tandem for SEE environment where the Smart Cards are the one who host the SEE codes while the HSMs do the Key Management. The reason is simply HSM's SEE isn't "owned" by you as you may have your codes reviewed before allowing to load them in the HSM's SEE environment (Safenet and Thales have their own SEE). A smart card environment is different.

As long as you have purchased a card with "Open Keys" a.k.a OP_READY mode, no one is going to vet your codes and you can load the smart card with your security critical codes and execute them in almost the same security as a HSM but with lesser speed, memory, 16 bit CPUs for most smart cards and somewhat lesser security due to the lack of tamper-backed battery protection but it still inherits other tamper resistant features from a HSM.

A HSM is usually known for generating stronger keys (destroyed after use via a key usage counter set to single use) so you can use the HSM to generate some random keys and encrypt random data sent from a user controlled smart card and receive the ciphertext which can then be hashed and then mixed with other user controlled cryptographic seeds (which are mixed - i.e. hashed again) to finalize a somewhat stronger cryptographic seed to insert into the CSPRNG of the smart card to be used to generate stronger keys which otherwise a smart card may not have the best CSPRNG output if left as default (factory card seed).

Smart card running a user's critical SEE may offload cryptographic operations to HSMs which runs them at a higher speed than smart cards and can be beneficial.

Public Key caching and public key operations can be sent to HSM since it's simply handling all the public keymat side which are not as sensitive as the private key side stored in smart cards that run SEE codes within a user's control. If the smart card has excess secret keys to handle, the smart card can wrap the excess secret key mats with it's own wrapping key and then send it to the HSM to cache them as well.

Thoth • August 14, 2016 10:41 AM

@Ergo Sum

Just avoid Windows if possible. There's still PDF and LibreOffice if there's a need for some level of inter-operability albeit inability of LibreOffice to be fully MS Office compatible which one can always ask clients to send their documents in PDF instead of MS Docs or Excel.

Thoth • August 14, 2016 11:40 AM

@Clive Robinson

If it is possible to request ASCII text, it would be the best option but the fact is no one would ever send ASCII text especially in the practical commercial world. Most company documents are in Document, PDF or Excel formats and these are all considered dangerous for security as we all know but there is no other option available and I wouldn't want to piss off my clients telling them I would only reply and send in ASCII text and no PDF or Word documents for my clients and same goes the other way round.

Even among security vendors, we don't exchange in ASCII format and instead some use highly visual Excel or Word document which may harbour dangerous macros. Not much can be done to industry standards (when Excel, PDF and Word reign supreme commercially and practically).

The only way out for most users is to have physically separated computers with physically partitioned networks and all the other stuff we discuss on not mixing personal with other category and having a multi-level and layer approach to categorizing and prioritizing one's personal security, privacy and work.

The same old thing which I have pointed, Linux and Windows are a gone case, OpenBSD is a plausible platform, microkernels are still in their "toddler" stage, high assurance ... well .. we only have @Markus Ottela's TFC for now but that's rather troublesome for the common users (who are mostly non-techies) to setup and use and even among us security conscious with technical know hows may not find it all too comfortable to deploy and use in terms of usability for now. The industry is poisoned by multiple interested parties who seek to control others for their own ends and benefits in a highly reckless manner. The open source community are still stuck at the level of software encryption with very low assurance methods (i.e. password + scrypt/hashing then encrypt in insecure CPU and OS) ... just too much layers to correct and fix to even have a little progress in security assurance. Poison of insecurity runs very deep to the core :) .

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 8:56 AM

@all

Why sensitive information should never be used outside insecure compartments or devices. @Clive Robinson and me have always been pushing for a separate secure encryption device with on-screen display and keyboard for the reason that the screen and input on your general purpose computing devices are simply not cut for handling sensitive information.

Link: http://www.theregister.co.uk/2016/08/15/retroscope/

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 15, 2016 10:57 PM

@all

Homomorphic encryption cracked. Still a long way to go to secure homomorphic encryption.

Link: http://www.theregister.co.uk/2016/08/16/researchers_crack_homomorphic_encryption/

Thoth • August 16, 2016 12:17 AM

@Wael

Yea. Data without encrypting it when it should have been data without decrypting it.

Thoth • August 16, 2016 5:11 AM

@Wael, Clive Robinson
I agree that he maturity of Homomorphoc Encryption is questionable and so far there are no single scheme mature enough for use. The report is simply a reminder that we don't quickly jump onto some new security algorithm or scheme and rationalize ot through.

It is not really about code cutting. It runs deeper in the sense nobody bothers to consider other platforms and scenarios or plan their security threat model and deployment model im depth. I am not sure if I did rant about how modern cryptographers take a rather myopic view when they design their algorithms amd schemes but for sure @Nick P would have heard me rant about it for a while.

If you look at why AES is still prevalent, one reason is people are too comfortable with some established standards and never thought through beyond that. If you botj remembered, I recently took steps to port 32-bit word ChaCha20 onto 8-bit smartcard platform and I the crap that have to be gone through re-writing 32-bit math into 8-bit stings but I still got it my way and ported an 8-bit variant.

Most cryptographers assumes some common Intel x86 or 64 platform and stuck theit algorithms to it. Similarly, many code cutters are too reliant on high level programmimg languages and never bother to go lower down the layers and attempt to understand them even a little.

@ianf

If you are very concerned about backdoors, build yourself your own CPU using transistors.

Link: https://hackaday.io/project/665-4-bit-computer-built-from-discrete-transistors

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 16, 2016 9:06 PM

@Dan3264, r

You need to understand that for @ianf and @Wael, they love sarcasm and so it's just read and then be it :) . That's the same tactic @Clive Robinson uses but he is much better at adapting and replying skillfully to both of their trolliness.

@Wael

Write the ciphertext in an under-garment with "invisible ink" and then pass it to your target :D .

@Dan3264, Clive Robinson

On a more practical note besides all the fun and fooling around above, making your own chips with the PUF and tamper mesh (I did talk about those last time - to @Nick P) but the fact is trust in the manufacturing which (myself, @Clive Robinson, @Wael, @Nick P, @RoberT et. al.) were not convinced of not getting some "additional gifts" inserted into the silicon. The reason @Clive Robsinson talked about Prison model is because the trust in the manufacturing of the silicon is pretty low on our list and it's better to just buy COTS materials and then mitigate the known threats.

I decided to use smart cards as the base of my security scheme due to the fact it's commonly available, using old architectures that rarely changes (for many decades) and are known to have rigorous tests and certifications done to ensure their minimal baseline of security they deliver. Die to it's sheer volume (i.e. SIM cards, smart cards, credit cards ...) and it's very wide variety of use cases from business and financial transactions, to physical door access, Government PIVs, telephone SIMs and public telephone cards ... it has a huge scope and therefore backdooring all of them (including all brands) would be extremely difficult plus the fact there's so much surpluses lying around to the point that legacy smart cards (NXP Mifare Classic, Infineon SLE 4428 ...etc...) are lying around. Despite these cards may or may not have the lastest cryptography engines, all it takes is for the cards to be tamper resistant and have enough RAM and EEPROM, it would not stop anyone from writing a software-based cipher to load into the tamper resistant card (even with outdated DES crypto). As you might have noticed, I wrote a ChaCha20 library for smart card with a pretty modest amount of RAM needed (130 bytes of RAM memory for the crypto library to work minimally, 48 bytes of RAM to hold the key, nonce and counter, 4 bytes for 2 pieces of 16-bit counters to operate the library by iteration automatic encryption or decryption, 208 bytes for output buffer and 256 bytes for input buffer). The total space required in memory at most is only 602 bytes and many smart cards supplies about 1024 bytes of RAM memory at least which is more than enough to implement an entire 256-bit ChaCha20 according to RFC-7539 in software without needing hardware crypto accelerators at all !!!

If course some people might be better than me at code-cutting and might reduce the 602 byte footprint somewhere to around 500 bytes or so and make the software library even more compact by splitting the library between ROM, EEPROM and RAM locations in a smart card thereby reducing the overall sizes even more.

It's always better to mix around in the crowds and as smart card IC chips are increasingly becoming a common place in the form of contactless payment or door entry cards to embedded SIMs and so on, I feel it's much better to use them. Instead of trusting their key generation feature, you could import keys and do software-only crypto as I have shown above albeit the slower speed and cumbersome extra library codes but this will definitely be more challenging to exflitrate since the smart card IC chip designed for very low power scenarios where the power may get disconnected anytime when the card is randomly removed, would find itself harder to have a sort of backdoor watchdog that keeps observing the executing codes because once the power is removed, the watchdog function would also be affected and reset with it needing to re-profile the codes all over again. A little obfuscation over the code libraries would suddenly become a huge headache for any backdoor watchdog function as it needs more RAM and EEPROM space to cache whatever codes it's observing and the fact that most smart card have meager RAM and EEPROM space with loading a single userspace applet program already taking up close to 75% of the internal card's RAM and EEPROM memory, it would become very very challenging to backdoor and also become very obvious due to extremely slow speed of the already slow 8/16-bit CPU of the smart card chip. With that in mind, obfuscating codes and putting in redundant data to try to hog up all the EEPROM and RAM space to prevent having free RAM and EEPROM space to be used by possibly malicious functions would be useful.

Also, the arguement is more RAM and EEPROM can be added to dedicated hardware backdoors but how much more can you squeeze when a 2mm x 3mm chip is using fabrication with bigger than 90nm (~ 250 to 350 nm legacy) technology ?

Thoth • August 16, 2016 9:09 PM

@Rex Rollman

If you consider software-based encryption as a legacy technique due to things like cold boot attacks on your laptop or desktop RAM, you should be moving to hardware-based encryption which I would say loading a suitable smart card with the open source OpenPGP applet and then use OpenPGP smart card encryption on the file.

Thoth • August 16, 2016 10:20 PM

@Wael

Sorry, I am no expert and don't pretend to be one. I am just doing a tiny effort with @Figureitout and @Markus Ottela to make all the nice theories that you, @Clive Robinson, @Nick P become as close to reality as possible on a practical and more down to earth level. Just trying my best with whatever small amount of time and resource I have at hand.

Regarding humour, I have nothing against it anyway. It's all good and I don't see anything wrong with the humour that you and @ianf brings to the comments section to lighten things up. My meaning of trolliness is referring to the humour but may how an Asian puts it is somewhat very inaccurate you know :) . Singlish (imperfect English) we call it in Singapore.

@Figureitout
I also added PGP code signing to my codes. Time to ramp up OPSEC with my PGP smart card. Going to sign all my other codes in my other projects. Of course code signing does not mean good quality codes with correct execution (which we have always discussed about).

Comments would be coming soon. I just need to update some codes to get the jcChaCha20 (smart card variant) to work and then add more comments. Regarding the manual re-init of the 32-bit counter, it is indeed a pain and can be rather slow but one scenario to be considered is in smart card projects, someone might lift the codes and may not want the automation. I am going to add the automation not in the MathUtil or ChaCha20 classes but inside the main class by connecting it to the smart card I/O sub-routine (process() method) for the fact that it seems more appropriate to live in the I/O sub-rountine there than bunch with the ChaCha20 class codes.

Thoth • August 17, 2016 4:40 AM

@Clive Robinson

I am aware of the problem of key fingerprint and for that matter I included a copy of the entire public key into every single Github repository I have signed with my PGP key to prevent people from looking elsewhere and finding some wrong public key or mistaking a wrong key instead just to make their life easier.

Thoth • August 17, 2016 8:45 AM

@Figureitout

jcChaCha20 is now fully functional with sample encryption and decryption of user data that can be called from the smart card APDU commands. Instructions on usage and comments have also been added.

Just a note that it might take 2 seconds or so to encrypt a 64 byte message due to the fact that it has to do 32-bit word downgrade to 8-bit word to process before upgrading it to 32-bit word and everything is done in software on a 16-bit smart card CPU.

Tested the encryption and decryption against the RFC-7539 test vectors and passed them.

Thoth • August 18, 2016 9:01 AM

@Curious

re: SRP

It's more of correct implementation of codes (a.k.a code quality). Security products requires high quality codes that are rigidly tested and checked to ensure bugs would not cause these kinds of problems (and also even better if the codebase is small and minimal). But the fact that even OpenSSL, OpenSSH and now SRP softwares can have bad quality codes with such dangerous bugs, it begs the question of what happened to high quality security codes.

Thoth • August 18, 2016 11:09 AM

@Gerard van Vooren

Complex standards leads to complex codes and thus the code qualities. It's quite straightforward since these libraries tries to be capable of a multitude of tasks and features but can you be sure that within next year or two, no researchers can come up with new cool-named exploits ?

I won't dare bet on the codes of OpenSSH nor OpenSSL. These stuff have too much codebase if you have ever downloaded and tried to peel them and read them before. I just took a glance and I decided not to step further. They have too much codes due to too much features.

Download one and take a look. Oh ... and there is no HTTPS so ... MiTM possibly.

Link: http://www.openssh.com/openbsd.html

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".

Thoth • August 19, 2016 12:38 AM

@r

re: Coding Bootcamp

How to code quick and code dirty :D . That's the latest trend these days. High assurance codes or probably just better quality codes are getting more rare.

Here's a very simple programming logic regarding a login module:

if userPIN.check(inputPIN):
...setLoginFlag(true);
...sendSuccessResponse();

It is tempting to terminate the logic once the check returns true and it sends a successful response. On a logical level, it should execute fine and looks OK but what happens when the context is put into an embedded chip (smart card) that uses a request/response ratchet (card reader and card).

If the above code executes, it will most likely fool a card reader thinking the authentication passes because the success response of a card defined in ISO-7816 is 0x9000 and if a code simply breaks from a loop and does nothing, it will also send 0x9000 by default which means everything is OK status.

If this were a card login system to login to a terminal, it would immediately unlock the terminal and give access even if you were to enter a wrong PIN. Of course this is too big of a blunder if you are a card developer (especially for security systems) but what I am saying is code qualities are pretty poor even in security systems (I am seeing daily) and that sort of nasty example I showed above can happen very easily when developing card systems.

I was reading through some smart card code signing applet and I thought the quality can be improved even more.

The above bug is just imaginary and not real if you didn't figure out. It was just to show a context that security codes must be rigid and strict.

Coding bootcamps would not necessarily help people to develop strict and better quality codes other than to give them additional knowledge on where to get started.

Code quality is more of a personality trait that must be developed by working under certain stressful conditions to meet certain requirements (i.e. to have a paranoid security mindset which @Bruce Schneier mentioned in Cryptography Engineering book he published).

Thoth • August 19, 2016 12:45 AM

@Wael, r, Nick P

re: Apples's Swift Language

I wonder how it stacks up against Mozilla's Rust since Swift also claims to be a Safe programming language.

@Nick P

Do you have any documents on how Mozilla's Rust VM works ? It would be interesting to dig into the VM and see if it's really robust against memory corruption and flaws.

Thoth • August 19, 2016 8:36 AM

@Clive Robinson

re: FHE

Do you still have the links for the Crypto Stack Exchange conversations or at least some old URLs of the discussions ? I can either use Time Machine or if it's still around at least mirror them and back them up on my website.

Thoth • August 19, 2016 12:01 PM

@Clive Robinson

Some materials:
- https://cryptome.org/2013/04/ciphercloud-dmca.pdf
- http://crypto.stackexchange.com/questions/3645/how-is-ciphercloud-doing-homomorphic-encryption
- http://www.ciphercloud.com/wp-content/uploads/2014/01/Best%20Practices%20for%20Protecting%20Content%20and%20Information%20in%20the%20Cloud_FINAL2.pdf

Will look around later when there is free time ... hopefully ...