BH18: Why so Spurious? How a Highly Error-Prone x86/x64 CPU "Feature" can be Abused to Achieve Local Privilege Escalation on Many Operating Systems

Nemanja Mulasmajic  and Nicolas Peterson are Anti-Cheat Engineers at Riot Games.

This is about a hardware feature available in Intel and ARM chips. The “feature” can be abused to achieve local privilege escalation.

CVE-2018-8897 – this is a local priv escalation – read and write kernel memory from usermode. Execute usermode code with kernel privileges. Affected Windows, Linux, MacOS, FreBSD and some Xen configurations.

To fully understand this, you’ll need to have some good assembly knowledge and privilege models. In the standard model, Ring 1 and 2 are really never used, just Ring 3 (least privileged) to Ring 0 (most) (it is a simplified view).

Hardware breakpoints cannot typically be sent by userland, though there are often ways to do it in syscalls. When an interrupt fires, it transfers execution to an interrupt handler. Lookup is based off of the interrupt descriptor table (IDT), which is registered by the OS.

Segmentation is a vestigial part of the x86 architecture now that everything leverages paging.  You can still set arbitrary base addresses.  The first 2 bits describe if you’re in kernel or user mode. Depending on the mode of execution, the GS base means different things (it holds data structures relevant to the mode of execution). If we’re coming from user mode, we need to call SWAPGS to update to the equiv in kernel mode.

MOV SS and POP SS force the processor to disable external interrupts, NMIs and pending debug exceptions until the boundary of the instruction following the SS load was reached. The intended purpose was to prevent an interrupt from firing immediately after loading SS but before loading a stack pointer.

It was discovered while building a VM detection mechanism, as VMs were being used to attack Anti-Cheat.. They thought – what if VMEXIT occurs during a  “blocking” period? Let’s follow the CPUID… They started thinking about what would happen if they did interrupts at unexpected times.

So, what happens? Why did his machine crash?  Before KiBreakpointTrap executes its first instructions, the pending #DB is fired (which was suppressed by MOV SS) and execution redirects to where KiBreakpointTrap, which sends execution back to where it *thought* it should go – kernel (though it had come from user mode).

Code can be found at github.com/nmulasmajic, if you aren’t passed, system will crash.  Showed demo of 2 lines of assembly code putting a VM into a deadlock.

They can avoid SWAPGS since Windows thinks they are coming from kernelmode.  WRGSBASE writes to the GSBASE address, so use that!

They fired a #DB exception at unexpected location, and then the kernel becomes confused. Handler thinks they are privileged, now they control GSBASE.  Now they just need to find instructions to capitalize on this…

Erroneously assumed there was no encoding for MOV SS, [RAX] only immediate. It doesn’t dereference memory, but POP SS does dereference stack memory. BUT… POP SS is only valid in 32-bit compatibility code segment. On Intel chips, SYSCALL cannot be used in compatibility mode. So… focusing on using INT # only.

With the goal of writing memory, found that if they caused a page fault (KiPageFualt) from kernelmode, they c ould call KeBugCHeckEx again.  This function dereferences GSBASE memory, which is under their control…

It clobbers surrounding memory. Had to make one CPU “stuck” to deal with writing to target location. Chose CPU1 since CPU0 had to service other incoming interrupts from APIC. CPU1 endlessly page faults, goes to the double fault handler when it runs out of stack space.

The goal was to load an unsigned driver. CPU0 does the driver loading. They attempted to send TLB shootdowns, forcing CPU0 to wait on the other CPUs by checking PacketBaerrier variable in its _KPCR. But, CPU1 is in a dead spin… will never respond. But, “luckily” there was a pointer leak in the +KPCR for any CPU, accessible from usermode. (the exploit does require a minimum of 2 CPUS).

It is complicated, and it took the researchers more than a month to make it work. So, they looked into the syscall handler – KiSystemCall64. They registered in the IA32_LSTAR MSR. SYSCALL, unlike INT #, will not immediately swap to kernel – actually made things easier. (Syscall funcions similar to Int 3)

Another cool demo J

A lot of this was patched in May. MS was very quick to respond, and most OSes should be patched by now. You can’t abuse SYSCALL anymore.

Lessons learned – want to make money on bug bounty? You need a cool name and a good graphic for your vuln (pay a designer!), and don’t forget a good soundtrack!

BH18: Lowering the Bar: Deep Learning for Side Channel Analysis

Jasper van Woudenberg, Riscure

The old way of doing side channel analysis was to do leakage modeling to pull out keys from the signals. Started researching what happens if they use a neural network for the analysis.

They still need to attach the scopes and wires to the device, can't get robots to do that, yet. They do several runs and look for variations in signal/power usage to find leakages from the patterns (and divergence of the patterns).

Then we got a demo of some signal analysis - he made a mistake, and noted that is the problems with humans, we make mistakes.

Understanding the power consumption can give you the results of X (X-or of Input and Key), then if we know input - we can get the key! Still a lot of work to do.

In template analysis, you build models around various devices from power traces - then look for other devices using the same chipset, and then can start gathering input for analysis.

The researchers than looked at improving their processes with Convolutional Neural Networks (CNNS). THere is the input layer (size is equal to number of samples), the convolutional layer (feature extractor + encoding), then Dense Layers (classifiers) and finally the output later. Convolutional layers are able to detect the features independently of their positions.

There are a lot of visuals and live tracing, hard to capture here, but fascinating to watch :-)

Caveat - don't give too much input, make the network is too big = or the model cannot actually learn and will not be able classify new things.  (memorizes vs learning).  Need to verify this with validation recall. 

Deep learning can really help with side channel analysis and it scales well. It does require network fiddling, but it's not that hard. This automation will help put a dent into better securing embedded devices.

BH18: Legal Liability for IoT Cybersecurity Vulnerabilities

IJay Palansky, Partner, Armstrong Teasdale

IJay is not a cyber security expert, but he is a trial lawyer who handles complex commercial litigation, consumer protection,  and class actions - usually representing the defendant.

There is a difference between data breach and IoT vulns. They aren't handled the same. There is precedent on data breaches, but not really much on IoT devices. People have been radically underestimating the cost and volume of IoT lawsuits that are about to come. The conditions are going to be right for a wave of lawsuits.

Think about policy. The rules are changing. It is hard to predict how this will play out, so it's hard to say how IoT companies should protect themselves. IJay likes this quote from Jeff Motz - "What would make 'defense greater than offense'..?" (Motz? maybe Moss?)

People are trying to get the latest and greatest gadget out, to get the first to market advantage. Security slows this down. But if your'e not thinking about security devices up front, you are putting yourself at risk. If you get drawn into litigation or the media draws attention to it, you need to be able to answer to the media (or a judge) what you did to meet basic security requirements for that type of device. Think of avoiding the liability. Judges will look for who is the msot responsible.

It's estimated that there will be 20 Billion connected devices by 2020.

There are ridiculous items coming online all the time - like the water bottle that glows when you need to drink, the connected Moen shower to set temperature, and the worst the i.Con Smart Condom... oh boy.

These devices have potential to harm, from privacy issues to physical harm.  There can be ransomware, DDoS attacks, etc. These are reality - people are remotely hacking vehicles already.

Plaintiffs' lawyers are watching and wating, they want to make sure they can get soemthing out of it financially. They need to be able to prove harm and attribution (who to blame). Most importantly, the plaintiffs' lawyers don't understand this technology (and neither do the judges), or how the laws here work.

There is general agreement that the security of IoT devices is not where they should be. There will be lawsuits, once there are some, there will be more (those other attorneys will be watching).

This is not the first time that product liability or other law has had to address new technology, but the interconnectedness involved in IoT is unique. They need to show who's fault it was - could get multiple defendants, and they will be so busy showing what the other defendant did wrong - doing the plaintiffs' lawyer's job for them. :-)

There has been some enforcement by regulators, like the response to TRENDnet Webcam hack in Jan 2012, which resulted in a settlement in 2013.

Some lawyers will be looking for opportunities to take up these cases, to help build a name and reputation.

The Jeep hack was announced in 2015, then Chrysler recalled the vehicles. That's not where the story ends... there is a class action lawsuit moving forward still. (filed in 2016, but only approved yesterday to go forward). This is where things get interesting - nobody was hurt, but there was real potential of getting hurt.   People thought they were buying a safe car, and they were not. What is the value?

There is reputation loss, safety issues, and the cost of litigation that makes this all a problem. It's a burden and distraction on key employees that have to be deposed, find documents, etc.

The engineers and experts get stressed about saying something that will hurt their company, or thinking that they did something wrong that hurt someone. That is a cost.

IJay then walks us through law school in 10 minutes :-)

You need to understand the legal risks and assocaited costs, so when you are making decisions on the right level of security.

Damages vary by legal claim and the particular harm. Claims can be around things like negligence, fraud or fradulent omission, breach of warranty, strict product liability.  These are all state law claims, not federal, which means there will be variance.

Negligence means you have failed tot take "reasonable care" - often based on expert opinions.  Think of the Pinto - they had design defects.

Design defets could be around hardware or software, things like how passwords are handled.

Breach of warranty is an issue as well - there are implied warranties, like of merchantability (assumption product is safe and usable)  If you know you have an issue, and don't tell anyone - that's fraudulent omission.

Keep in mind that state statutes are dsigned to be cosnumer friendly, with really broad defintiions.

You need to minimally follow industry standards, but that may not be sufficient.

Think about security at all stages of your design, be informed and ask the right questions, be paranoid and allocate risk. Test and document the testing you did, save it while you do the work. It will hep protect you.  Be careful about words you use around your products, watch what you say in your advertisement and don't overstate what you do.

You should also get litigation insurance and make sure it covers IoT.

If it goes wrong - get a  good lawyer who knows this area. Investigate the cause, inclding discussions with engineers.

A wave of IoT hack and vuln litigation is coming - you need to be thinking about this now. Understand and use sound cybersecurity design and engineering principles.

BH18: AI & ML in Cyber Security - Why Algorithms are Dangerous

Raffael Marty, VP Corporate Strategy ForcePoint

We don't truly have AI, yet. Algorithms are getting smarter, but experts are more important. Understand your data and algorithms before you do anything with them. It's important to invest in experts that know security.

Raffael has been doing this (working in security) for a very long time, and then moved into big data. At Forcepoint, he's focusing on studying user behavior so that they can recognize when something bad is happening. ("The Human Point System")

Machine learning is an algorithmic way to describe data. In supervised case, we are giving the system a lot of training data. Unsupervised, we give the system an optimization for it to solve.  For "Deep Learning" - it is a newer machine learning algorithm. It eliminates the feature engineering step.  Data mining is a set of methods to explore data automatically.  And AI - "A program that doesn't simply classify or compute model parameters, but comes up with novel knowledge that a security analyst finds insightful" (not there, yet).

Computers are now better than people at playing chess and Go, they are even getting better at designing effective drugs and for making things like Siri smarter.

Machine learning is used in security, for things like detecting malware, spam detection, and finding pockets of bad IP addresses on the Internet in supervised cases, and more in unsupervised..

There are several examples of AI failures in the field, like the Pentagon training AI to learn tanks (they used sunny pictures for "no tank" and cloudy with tanks, so the AI system assumed no tanks were in sunny weather... ooops!)

Algorithms make assumptions about the data, they assume the data is clean (often is not), make assumptions about distribution of data and don't deal with outliers.  The algorithms are too easy to use today - the process is more important than the algorithm.  Algorithms do not take domain knowledge into account.  Defining meaningful and representative distance functions, for example.  Ports look like integers and algorithms make bad assumptions here about "distance"

There is bias in the algorithms we are not aware of (example of translating "he is a nurse. she is a doctor" from English to Hungarian and back again... suddenly the genders are swapped! Now she is a nurse....)

Too often assumptions are made based on a single customer's data, or learning from an infected data set, or simply missing data.  Another example is an IDS that got confused by IKE traffic and classified it as a "UDP Bomb".

There are dangers with deep learning use. Do not use if there is not enough or no quality labelled data, look out for things like time zones along with timezones. You need to have well trained domain experts and data scientists to oversee the implementation, and understand what was actually learned.
Note - there are not a lot of individuals that understand security and data science, so make sure you build then a good, strong and cohesive team.

You need to look out for adversarial input - you can add a small amount of noise to an image, for example, that a human cannot see, but can trick a computer into thinking a picture of a panda is really a gibbon.

Deep learning - is it the solution to everything? Most security problems cannot be solved with deep learning (or supervised methods in general). We looked at a network graph - we might have lots of data, but not enough information or context nor labels - the dataset is actually no good.

Can unsupervised data save us?  Can we exploit the inherent structure within the adta to find anomalies and attacks?  First we have to clean the data, engineer distance functions, analyze the data, etc...

In one graphic, a destination port was misclassified as a source port (80!), and one bit of data had port 70000!  While it's obvious to those of us with network knowledge that the data is messed up, it's not to the data scientists that looked at the data. (with this network data, the data scientists found "attacks" at port 0).

Data science might classify port 443 as an "outlier" because it's "far" from port 80 - but to those of us who know, they are not "far" from each other technically.

Different algorithms struggle with clustered data, the shape of the data.  Even if you choose the "right" algorithm, you must understand the parameters

If you get all of those things right, then you still need to interpret the data. Are the clusters good or bad? What is anomalous?

There is another approach - probabilistic inference. Look at a Beysian Belief Networks. The first step is to build the graph, thinking about the objective and the observable behaviors. If the data is too complicated, may need to introduce "grouping nodes" and introduce the dependencies between the groups. After all the right steps, you still need to get expert opinions.

Need to make sure you start with defining your use-cases, but by choosing an algorithm. ML is barely ever the solution to your problem. Use ensembles of algorithms and teach the algos to ask for input!  You want it to have expert input and not make assumptions!

Remember - "History is not a predictor, but knowledge is"

BH18: Kernel Mode Threats and Practical Defenses

Joe Desimone, Gabriel Landau (Endgame)

Looking at kernel attacks, as it is a method to take over the entire machine and evade all security technology. Historically, Microsoft was vulnerable to malware - not prepared for those types of attacks, but they have made improvements over the year with things like PatchGuard and Driver Signature Enforcement. PatchGuard isn't perfect, attacks get through, but MS is constantly updating so the attacks don't work for long.

Both of these technologies are focused on 64-bit kernels, which is the growing norm today.

Attackers are now using bootkits, so Microsoft and Intel have come up with technology to counter (Secure Boot, Trusted Boot, Itnel Boot Guard, and Intel BIOS Guard).

All of those protections have changed the landscape. We don't see millions of kernel based botnets out there anymore.  But now people are signing their malware to look more legitimate and trick people to install.

DUQU 2.0 was a nation state attack, main payload used 0day in win32k.sys for kernel execution (CVE-2015-2360), it was spoofing process information to route maliious traffic on the internal network.

With the introduction of virtualization based security has also made the system more secure against things like Uroburos, Duqu2, DoublePUlsar.

The MS kernel has been greatly evolving over the last 10  years to greatly improved their mitigations. But, the problem is the adoption rate. There are still a lot of systems running Windows 7, which does not benefit from these new protections.

The speakers are on their orgs red team, so they are always looking for new ways to attack the system. They want to avoid detection and signature checks - their blue team is on the lookout for user mdoe priv escalation, so they wanted to be in the kernel. Looked at sample code from Winsock Kernel, found it was very effective (no beacons).

Did find a good attack, which means they needed to improve their own security.

Modification of kernel memory can significantly compromise the integrity of the system, so this is a major area of concern.

Need chip manufacturer to ship hardware with ROP detection enabled, otherwise this will always be a vector of attack. They did this by creating a surrogate thread, put it to sleep and though foudn the location of the stack and take advantage of it. (more details in the deck, the slides move pretty fast), but the interesting thing here is how much they can do by reusing existing code.

To project yourself, you should very carefully monitor driver load events. Look for low prevalence drivers and known-exploited drivers.  You need hypervisor protection policies, using white lists (which are hard to maintain) and leverage kernel drivers to WHQL. They have made a new tool to also  help to reduce the attack surface, available on their website today.

They wrote some code to generically detect function pointer hooks, locate the function pointers by walking relocation tables and leverage Endgame Marta.  They consider it a hit if it originally pointed to +X section in on-disk copy of driver, does not pont to a loaded driver in memory and points to executable memory.
 
ROP generates a lot of mispredictions, so need to protect this area as well (they could attack by scanning drivers to identify call/return sites, configure LBR to record CPLO near returns, etc)

The talk had lots of cool demos - can't really capture it here.

Windows platform security has gotten much better, but tehre are still kernel threats. You need to be using at least Windows 10 with SecureBoot and HVCI. at a minimum to protect yourself. Requite EV/WHQL within your organization

BH18: Don't @ Me: Hunting Twitter Bots at Scale

Jordan Wright, Olabode Anise, Duo Labs

Social media is a great way to have genuine conversations online, but the sphere is getting filled with bots, spam and attackers.

Not all bots on twitter are malicious - they could be giving us automated data on earthquakes, git updates, etc. So, their research was focused on finding bots and then figuring out if they were malicious.

The goal here is to build a classifier, one that could learn and adapt.

They wanted their research to be reproducible, so used the official Twitter APIs - though by doing so, they were rate limited. Because they were rate limited, they needed to be as efficient as possible. Fitting into that model, they were able to look up 8.6 million lookups per day.

Twitter's account ids started as sequential 32-bit unsigned integers, but the researchers started with random 5% sampling. The dataset has gaps - closed accounts, etc. Noticed accounts went up to very large numbers, and those accounts were up to 2016. But, Twitter changed to using "Snowflake IDs" - generated by workers, same format as other Twitter ids (tweets, etc).

The Snoflake ID is 63-bit, but starts with a timestamp (41-bits), then worker number (10 bits), then sequence (12 bits). It is very hard to guess these numbers. So, they used the streaming API with a random sample of public statuses (contains the full user object).

Now - they have a giant dataset :-)

Looked at last 200 tweets, accounts with more than 10 tweets, declared English and then they fetched the original tweets.  This data was too hard to get - could only do 1400 requests/day.

They took the approach of starting from known bots and discovering the bot nets they were attached to.

The data they have include attributes (how many tweets, are they followed, in lists, etc), looking at tweet content (lots of links?), and frequency of tweets.

They examined the entropy of the user name, was it fairly random? Probably a bot. Same for lots of numbers at the begining or end. Watchin for ratios of followers to following and the number of tweets.

They applied heuristics to the content - like number of hashtags in tweets, number of URLs (could be a bot or a news agency!), number of users @ replied.  On behavior - look at how long it takes to reply or retweet, and the unique set of users retweeted.  Genuine users would go queit for periods (like when sleeping).

Then we got a Data Science 101 primer :-)

This is where it gets complicated and statistics come into play, and the reminder that your model is only as good as your data. For example, if they trained with the crypto currency bots, they found 80% of the other spam bots. when reversed, they only caught about 50% of the crypto currency bots.


 Crypto currency give-a-way accounts are very problematic - they look legitimate and they will take your "deposit" and then you will lose your money.  They were hard to find, until they realized that there are accounts are out there that have many bots following them. Find those legitimate accounts, then you can find the bots.... also following like behaviors, used to map relatinships.  They found mesh and hub/spoke networks, but they were connected with likes.

They also discovered verified accounts that had been taken over, then they are modfiied to look like a more active account (like Elon Musk) that adds legitimacy to the crypto currency spam.

Very interesting research!

BH18: Blockchain Autopsies - Analyzing Ethereum Smart Contract Deaths

Jay Little, Principal Security Engineer, Trail of Bits
Trail of Bits is a cyber security research company - high end security research and assesments.

Earlier this year he was working on a project with a friend to look into an aspects of contracts

Ethereum, EVM and Solidty

Ask for a show of hands about who has bought Ethereum here, lots of hands went up.

Ethereum is a blockchain based distributed ledger, called a "world computer" and has "smart" contracts. It is the 2nd largest crypto currency.

The Ethereum Virtual Machine (EVM) is a big endian stack machine with 185 opcodes, native data width is 256 bits, whith many similar instructions. Each instruction has a 'gas cost' to prevent infinite loops.

Most contracts start at 0, there are 5 addresse spaces. Most people don't write their contracts in EVM, but use Solidty instead - it's a JavaScript inspired high level language for smart contracts. It has evolved (as opposed to being designed).

Much of the presentation is done with emoji's - easier to see than a string of numbers :-)

 Because contracts start at zero, he has seen undefined behaviors when counters get decremented too low.  ALso issues with unintialized variables - used in one case to backdoor a lottery system.

There is a new tool, Rattle, recovers EVM control flow.  Other tools, Geth and Party, run on public nodes. This followed by a walkthrough of using the tools and their CLI options and looking at a some contracts.  He shared the code for finding contracts as well.  Geth and Parity have a lot of issues, so he's been looking at etherscna.io - a quick lookup database.

Doing a hybrid approach of using Geth and Parity to find the contracts over a few hours, then look into eherium.io.  Looking at 6M blocks, about half are duplicates. Some are empty, but have a balance - which shouldn't happen.

Sometimes the contracts fail, because they did not use enough 'gas' . Found a contract with no code (unusable) but with about $7000 in it - stuck there forever.  All told, there is about $2.6M stuck in empty contracts that can never be retrieved.

Some duplicates have infinite loops - could be intended as a network DoS. Others seen with noise or spam, or NUL value issues

From tracing they were able to look into contracts where the self destruct was not the original creator - they tend to send the money to address 0, losing it forever. 

If you are developing contracts, make sure you understand and fix all warnings. Add an Echnidan test and write extensive positive and negative tests. Most importantly, perform a rigorous assessment!

ICMC17: Thomas Jefferson and Apple versus the FBI

Daniel J. Bernstein, University of Illinois at Chicago & Technische Universiteit Eindoven

Gutenberg's original printing press was based on a wine press - who knew? If you think beer or wine is dangerous, you may think the best thing to do is prohibit alcohol. In 1919, the Womens Christian Temperance Union requested that the public library to remove books and pamplets on the home production of alcohol for drinks. the librarians would not destroy the books, but did remove them from public access.

Why do censors try to ban instructions? "It might be bad if people follow these instructions" - stop people from acting on information.   We have freedom of speech, though, so we shouldn't accept this. You can try to hide the information, but they will still find it and figure it out. Censorship adds very little benefit, and often causes massive damage.

There are careful exceptions to free speech in the US- you cannot intentionally solicit criminal activity. You also cannot advocate an imminent lawless action if it's likely to produce such an action: "Let's burn down that mosque" - not protected by free speech.  You also can't make false promises (breach of contract), deceive people for profit (fraud), or make false statements that damage reputation with reckless disregard for the truth (defamation).

What about training videos? Is Ocean's Eleven a training video? What about Tom Clancy's Debt of Honor, 1994 that described something very similar to 9-11 attacks. Some people also don't want to see historical documents and books on things like Kamikaze pilots - what if terrorists act on these examples?  It turns out they will come up with it themselves, even without such inspiration.
So, the court has to look at it from the point of view - are you intentionally aiding and abetting criminal activities?

What if a terrorist stays hidden and alive in the woods by reading a book on "how to fish"? It's clearly not intended to help criminals.  That type of book is protected under free speech.

On software - it's usually (always?) something a human could do/calculate by hand, with time, but we're using the computer to help make it faster. If you hear statements from the government that is talking about restricting computers - remove the word "computer" and see if the same rationale for censoring instructions followed by people?

People are using encryption to protect files and conversations, as the FBI calls it "going dark".  So, should we be allowed to publish encryption software?  Imagine if you remove the computer from this situation

Jefferson and James Madison communicated via 'encrypted' messages, encoded. Thomas Jefferson distributed instructions that James Madison used, by hand, to encrypt private letters. No computer involved here, doing it by hand. What if they  published how to do this in a book? And then a criminal used it, and the FBI comes and says you can't publish this. Is that allowed? If the book is intended to help criminals, the government can censor.

Lawyers will claim that free speech needs a software exception. Imagine sw made to destroy navigational systems on airplanes? What if it was a book that described how to do this? The computer is irrelevant to the question. The courts should look at the intent, just like they do when you present them with a book.

According to the FBI, in 1963, the Domestic Intelligence head thought he was a Russian agent. In 1964 he won the Nobel Peace Prize. In 1964 FBI sent King an anonymous letter encouraging him to commit suicide.  In 1967, NSA also started surveillance on King.

As far back as 1977, the NSA (Joseph Meyer) threatened  organizers of a crypto conference with prosecution under export laws.

For Dan himself, he sent a crypto paper and crypto software to NSA asking them for permission to publish. NSA refused, classifying paper and software as "munitions" and subject to export control.  Though in 1995, the NSA told the courts they were trying to protect America - but papers were okay (free speech) and allowed Dan to publish the paper (but not the software).

Unfortunately for the NSA, Judge Marilyn Hall Patel disagreed with them in 1996, and agreed that software was free speech. It's just language. The court of appeals agreed in 1999.

Now back to modern day - Apple vs FBI - but imagine w/out the computer. Imagine the FBI coming to Jefferson and demand that he write a new anti-encryption instructions and falsely sign those instructions as being legitimate.  Jefferson says that the instructions are too dangerous to create. The US Supreme Court notes that freedom of speech includes "both what to say and what not to say".

Ask yourself - what is the software doing in this picture?  What if we were doing this ourselves? The courts know how to handle that and you should, too.

OASIS PKCS11 TC Published PKCS#11 2.40 Errata 01 and Header Files!

After we released PKCS#11 2.40, the PKCS11 Technical Committee and our public reviewers found some issues. I'm proud of the work the technical committee did with the public to create  Errata documents for PKCS#11 2.40.

These documents, where created, supersede PKCS#11 v2.40. That is,  if there is an updated constant identifier in the Errata, that should be considered correct.  The PKCS#11 2.40 Usage Guide remains the most up to date, and it is a committee note (not a standard).

In addition to the updated errata documents, we are excited to launch our first official set of header files since moving under the OASIS banner (aka "normative computer language definition files"): pkcs11.h, pkcs11f.h, and pkcs11t.h.

The PKCS11 TC has published Approved Errata for PKCS #11 V2.40. See the announcement at https://www.oasis-open.org/news/announcements/pkcs-11-v2-40-approved-erratas-published-by-pkcs-11-tc or use the links below.

• PKCS #11 Cryptographic Token Interface Base Specification Version 2.40 Errata 01
  http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/errata01/os/pkcs11-base-v2.40-errata01-os.html
• PKCS #11 Cryptographic Token Interface Base Specification Version 2.40 Plus Errata 01
  OASIS Standard Incorporating Approved Errata 01
  http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/errata01/os/pkcs11-base-v2.40-errata01-os-complete.html
• Normative computer language definition files
  http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/errata01/os/include/pkcs11-v2.40/

• PKCS #11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40 Errata 01
  http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/errata01/os/pkcs11-curr-v2.40-errata01-os.html
• PKCS #11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40 Plus Errata 01
  OASIS Standard Incorporating Approved Errata 01
  http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/errata01/os/pkcs11-curr-v2.40-errata01-os-complete.html

• PKCS #11 Cryptographic Token Interface Historical Mechanisms Specification Version 2.40 Errata 01
  http://docs.oasis-open.org/pkcs11/pkcs11-hist/v2.40/errata01/os/pkcs11-hist-v2.40-errata01-os.html
• PKCS #11 Cryptographic Token Interface Historical Mechanisms Specification Version 2.40 Plus Errata 01
  OASIS Standard Incorporating Approved Errata 01
  http://docs.oasis-open.org/pkcs11/pkcs11-hist/v2.40/errata01/os/pkcs11-hist-v2.40-errata01-os-complete.html

ICMC15: Importance of Open Source to the Cryptographic Module Community

Chris Brych, Senior Principal Security Analyst, Oracle

Chris's talk will focus primarily on OpenSSL's history and potential future

The OpenSSL project has it's roots back to 1995 to the SSLeay project (Tim Hudson and Eric Young). In 1998, Tim and Eric joined RSA and started a new life and career in crypto development. There were still a lot of followers, Ben Laurie and Dr. Stephen Henson took over maintenance and changed the name to OpenSSL. In January 1999, 0.9.1 was released. Mostly maintained by volunteers. Today, we're at 1.0.2d.

There are 15 people around he world that work on OpenSSL, most are volunteers. There are 2 full time paid employees with plans to hire 2 m ore. No direct source of funding, they are relying on some private contributions and some donations.  Considering there are 7,098,576 web servers use OpenSSL (0.9.7 -> 1.0.2). This does not include application uses of OpenSSL, either, like routers.

In 2003 Steve Marquess, working for US DoD, embarked on a FIPS 140 project to validate a cryptographic toolkit derived from an OpenSSL distribution to get around exorbitant licensing fees from 3rd party toolkit vendors.  Needed a more cost effective solution.

There was a fork created in OpenSSL distribution to isolate the FIPS crypto into it's own distribution. There is a build process that is repeatable to build the exact same module that has already been validated. The hash was calculated over the fipscanister.o and verifying it with a hash published in the FIPS security Policy Document guaranteed that the same code that was validated could be used to build the FOM. Contiguous boundary created in memory that allowed for integrity checking.

This was based on the 0.9.7e distribution.  But, the DoD still wanted to make some changes to make it eve more secure.

The community saw value in someone else doing this work and started picking this up and then making contributions upstream to make it more secure.

Why use this? Well - it's free!  (subject to license restrictions).  If you're a small company, you can't afford the cost of 3rd party toolkits with FIPS support.

There's also low internal maintenance, because OpenSSL does it for you. Engineering can focus on new development features, new updates can be picked up and easily integrated and build on existing code base.

Since this was so widely accepted by many companies, many vendors stopped making their own crypto libraries. Many people, beyond the 15 core volunteers, contribute fixes.

There are disadvantages....

For example, if a bug has been publicly identified, it is out of your control - you have to wait for OpenSSL to create a fix.  You may need to wait on OpenSSL to re-certify itself, slowing down your business.  OpenSSL is not for everybody - the 80/20 rule applies here.

0.9.8 and 1.0.0 OpenSSL distributions will be EOL on December 31, 2015.  The FIPS Object Module version 1.2.4 (Cert #1051) will no longer be supported.

1.0.1 is EOL December 31, 2016 - so start thinking abou going to 1.0.2. FIPS Object Module cert #1747 is still supported by 1.0.2

But, 1.0.2 will only be around until December 31, 2019. Seems a long way out, but it will be here before we know  it. Then, we won't have anything to use #1747 with anymore.

NIST just published a draft of SPF 800-131A, r1 in July 2015, speifies non-compliant DH, ECDH and RSA in 2018.  the FIPS Object Module is not fully compliant with NIST SP 800-56A/B key agreemen. So only primitives testing for ECDH completed, KDF not tested. DH not tested as part of NIST SP 800-56A and RSA not compliant with SP 800-56B and OpenSSL does not plan to do this development.

1.1.0 is plan to be released in April/May 2016, which will include an API change. It will not be compatible with FOM 2.0.10.  That is, we lose our FIPS module!

This means that if organizations need FIPS and are now relying on OpenSSL, they will have to hire to complete this. Will have to make modifications of a code base containing over 500,000 lines of code - risky. What if they introduce other vulnerabilities?  Many vendors will have an OpenSSL validation - but they won't be the same. Confusing for end users.

Money won't solve the problem. OpenSSL is not interested, even if some vendor offered them money.

How can we solve this? if you're interested, please participate in the CMUF. We will have to get input from CMVP and the US Government needs to be involved.

Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: Collateral Damage—Vendor and Customer Impact of Frequent Policy Changes

Joshua Brickman, Director, Security Evaluations, Oracle; Glenn Brunette, Senior Director and Chief Technologist, Cybersecurity, Oracle

Glenn started the talk.

Oracle is a big company, nearly 40 years old. Originally started with one products, but no has 1,000s of products with 400,000 customers across 145 countries.  This is a lot of variance, which makes doing FIPS 140-2 at Oracle a challenge.

Many of our products and delivered systems cannot change frequently, for example products used in medical trials.

Oracle has developed many products for FIPS 140: Solaris Cryptographic Framework, StorageTek, Java Cards, Acme Packet Session Border Controller, etc.  Also leverage third-party validated modules ("FIPS Inside") like RSA BSAFE Crypto J and OpenSSL.

It's not even simple when you talk about one product. For example, our Database interacts with several different crypto modules.

We do our best to educate our customers and internal developers, try to figure out how to compare apples and oranges and figure out operational decisions.

FIPS 140 can be easy to understand in one breath, and complicated to understand in the second. Is it approved or not?  Validated vs approved?  What modes and key lengths are you validated against?

We need to be more specific.  Marketing and product documentation might say: "We're FIPS validated! We're Encrypted" - but our customers want and need more details. Even saying a product uses AES may not be sufficient, as they need to know modes supported.

Module vs product validation.  Is "Oracle Weblogic" FIPS 140 validated?  What about Oracle Solaris? It could have multiple libraries and modules under the covers.

But, if you use "FIPS Inside" approach, you won't be listed on the CMVP website, so customer doubts vendor's sincerity.  Would be nice  if there was an official place to list folks leveraging FIPS Inside strategy.

Module versioning is not consistent with product versioning.  You can get away with very vague versioning schemes, makes it challenging for customers.

How do you map a product's cryptography to modules?  The big product, like an OS, may not validate every cryptographic module included in the system. Even if the OS vendor works really hard, they might only get 80%. How does your customer know if they are using one of the non validated uses cases?

Many times products do not ship with FIPS 140 on by default, so there is a challenge to even get it turned on. Then, customers layer products - particularly in the cloud space.

The NIST website can be very clear about when you should use FIPS, yet customers don't interpret this correctly. They may only be concerned with TLS, but actually using more.  They've sometimes done the horrible workaround to drop crypto, because they don't have a validated solution.  Some customers get this, others do not.

Lack of understanding at the customer site leads to a lot of problems. We need to plan for this when making future standards, so folks aren't taking the shortest path (which is usually the wrong approach).

Josh thinks there's a lot of hope, he sees progress coming around the corner.

It's clear that NIST/CMVP want the strongest crypto NOW for their customers. Vendors want the strongest crypto for their customers, with the least performance impact. Customers WANT this, but for a low price.

Remember the critical Shampoo algorithm: lather, rinse, repeat! This should apply to the CMVP process.

Vendors face big challenges, like: AES-GCM IV Generation.  In 2007 NIST issued SP 800-38D published, with two IG's.  In 2009 IG A.5 Key/IV pair uniqueness requirements  inside the physical boundary. In 2015 IG A.5 was overhauled, based on the discovery of 1 vendor's bad application that used all zeros for their IV - so we're all punished. Change came in August 2015, no grandfathering.

When we saw the new IG draft, we stopped all ongoing work to analyze the new IG. Oracle wrote up a proposal to mitigate the impact of the new IG while still meeting the spirit of the IG and sent it to CMVP.  Whiel waiting for a response, CMVP issued another IG. On August 5, still not responding to Oracle's comments, A.5 came out. How is that working with the vendors?

IG 7.15 published in August, again no grandfathering, and we found a project that got it's entropy from a 3rd party and we could not prove it.  the third party treated this as intellectual property, so they did not want to work with CMVP.  Oracle volunteered everything we did know to CMVP, and begged for a waiver. How do you build a business around that model?  Did everyone get a waiver?  Will our next project get a waiver?

How do we get out of that cycle?

Could form a technical community (CMUF working with CMVP). Take a page from NIAP and work together to solve problems. Take advantage of the fast resources of industry!  Create one for IGs, one for FIPS 140-4, etc.  Instead of throwing IG's over the wall, work together to come up with consensus.

We need time  to react - there MUST be time to transition. Every reactive response to IG is less time for industry to build product and fix bugs. [Note: by panicking to react, we may end up introducing worse issues.]

NIAP and NIST need to go back to being a partnership - see Entropy!

Negotiate with other crypto schemes to see if any mutual recognition can be negotiated.

We can do better by working together, so let's do that :-)

Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: FIPS is FIPS, Real World is Real World and Never the Twain Shall Meet?

Ashit Vora, Co-Founder and Laboratory Director, Acumen Security

Ashit's journey has taken him from a Lab, then to a Vendor, and now back to a Lab.  He's seen the experience from both sides.  He's been working with FIPS 140-2 since 2003. The world has changed greatly since then, but the standard has not.

FIPS 140-2 has been approved since May 2001. It was very hardware focused, as that's what was common in the marketplace. There was only a small handful of approved algorithms.

There is a requirement that the standard is supposed to be updated every 5 years, so there was a draft of FIPS 140-3 in September 2005... a draft.  As of now, we *might* get FIPS 140-3 in May 2016, if it's delayed even a little bit it will turn into a long delay, as the standard has to be signed off by the Secretary of Department of Commerce - a political appointee, which will change when there is a new US President.

FIPS 140-2 is an open commercial project. The standard itself is 69 pages. Many vendors read that only and say, "I've read and understand the standard and we're ready!"  There are 127 pages of Derived Test Requirements, and 63 pages of implementation guidance.  IG was originally supposed to be an FAQ, but it has evolved to really be the new rules.

There are 287 requirements for FIPS, 50% of them are documentation requirements. More than 50% of the requirements are orthogonal to crypto.

OpenSSL has had 5 vulns in 2013, 22 in 2014 and 26 in 2015, but how many times has their FIPS module changed since 2013? Zero.

CMVP believes FIPS is a solutions, vendors think it's a means to an end (to sell to the government), and to the federal agencies it is merely a checkbox.

What is it really? A bit of everything and a bit of nothing. Ensures what is claimed has been implemented correctly - that's a good thing! At levels 1 and 2 little more assurance than the product implements crypto as per spec. FIPS validation does not mean the overall "cryptographic posture" of the system is secure.

The standard was developed with the best intentions, but it has not been able to change with our fast changing industry.  There have been a few improvements, like the changes for CRNG relaxation and possible relaxation on integrity checks.

COTS product - easy to buy a produce and open at your own leisure. Causes vendors to downgrade to level 1 or design prupose built "opacity shields". Tamper labels in a similar vein add nothing to security posture of the product. Products are rarely deployed with the opacity shields and tamper labels in place, they just don't fit on the rack. Plus, end users need to make modifications.

Real world: Key Management - possible to have a module FIPS validated w/out including key management at all. In fact MOST software libraries do not include key management.  This is a direct result of crypto boundaries shrinking!

Password requirements are rudimentary at best. No consideration for password complexity, frequency, etc.

Real World: OpenSSL. It is the MOST widely used cryptographic library in the world.  ost prevalent in networking products, but also showing up in IoT, etc. Many products gain FIPS compliance just by including OpenSSL.  That validation, however, does not cover TLS, key management - etc. Hence, the small boundary.

FCC/FSM and configuration management requirements do NOT add security.  The FSM (Finite State Machine) is almost always created AFTER the product is completed.

We have a test on software firmware load test, it checks that it's valid, but there is no root of trust.  A self signed cert gets you through this check.

Should follow the CC direction: use the standard as a base/toolkit and provide technology specific requirements (that map back to the standard).

Do not tie validations to specific versions. Allow for minor changes/bug fixes. Validations take a long time (12-18 months), but vendors tend to push fixes every month. Often very minor. Yes, there may be that one corner case where one vendor screws this up and makes a critical change - but why punish all vendors for one person's mistake?

Due to this, vendors are making VERY small boundaries, which means we're actually looking at a tiny portion of the security relevant system. Need to encourage larger boundaries, but that's only possible if engineers can fix small bugs.

Spend time on the most important sections: Section 1, Section 5 and Section 7.

Focus on key life cycle! Make those requirements more all-encompassing. Implementing crypto algorithms is easy (?!?), but key management is hard. [NOTE: it's all hard :-)]

Question what about making physical security optional?  Maybe, but it should be tied to the expected deployment environment. For example, a publicly accessible wifi access point might need to be more strict than a router buried in the bowels of a government building.

Randy Easter recommended just doing Level 1 for physical security, but Ashit noted that if they do everything else to Level 2 they will end up with a Level 1 overall validation. Randy noted that this is a matter of informing end customers - easier said than done!

Randy also wants to know how CMVP has relaxed rules w/out notifying the Secretary of Commerce?  Ashit noted that "that ship has sailed" with the Implementation Guidance.

Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: Commonly Accepted Keys and CSPs Initiative

Ryan Thomas, FIPS 140-2 Program Manager, CGI Global Labs

Vendors understand their products and security, but are mystefied with how to list keys/CSPs in the way that the CMVP want.

The labs understand the requirements, and review any different types of vendor submissions that meet the requirements - and really want to provide something that is consistent and easy to review by CMVP.

Ryan has the idea to make life simpler, by creating a shared template for Keys and CSPs table.  He's gotten feedback already from CMVP.

Vendors will benefit from a pre-populated list that they can customize to your implementation - saves time and effort!

This isn't perfectly straight forward - will vary by software vs hardware modules.  Does it have persistent or ephemeral keys?  If it's software, likely are not making key storage claims.

Picture of template.....

Column #1 - Key/CSP Name. Mapped to NIST SP, ISO or IETF RFC - ie normalized names, a consistent and clear name that means the same thing to everyone.

Column #2 - Key/CSP type - type of key, algorithm and size.

Column #3 - Generation Input. Explain how the keys are derived or generated. If it's entered, specify if the CSP is entered electronically or manually/encrypted or plain text.

Column #4 - Output - encrypted or plain text

Column #5 - Storage. is it stored in memory, flash, HD, etc. ( encrypted or not). (there seemed to be 2 #4 columns,  so my numbering is off).

Column #6 - Use. how is the key used during module operation?  Needs to be mapped directly to an approved service that the crypto module performs.

Column #7 - Zeroization. How will the CSP be zeroized?  All possible techniquest need to be listed.

As for case studies, Ryan started with a "simple" IST SP 800-90A hash based DRBG.  Still found some inconsistencies.

More difficult are network protocols, like SSH, SNMP, IPsec and IKE - IKE is particularly tough.

TLS has a lot of potential rows, so want to work with the CMVP on this one as well, before showing to the public.

This will get posted to the CMUF (Cryptographic Module User Foundation?) site, contact Matt Keller if you need access.

Jennifer Cawthra, CMVP Program Manager, NIST - notes that this would really be appreciated, as it will help speed up their reviews, etc.  They are also looking for a security policy template - which the CMUF is also thinking of picking up.

From a vendor perspective, this looks pretty cool.  I think by having a standard template, we could then freely discuss with other vendors and not have to worry about disclosing some proprietary format, there could be websites to help walk us through, etc.


Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: CMVP Programmatic Status

Carolyn French, ITS Engineer, CSE; Michael Cooper, IT Specialist, NIST; Apostol Vassilev, Cybersecurity Expert, Computer Security Division, NIST

NIST will be increasing he fees for one year, cost recovery fees, so that they can hire contractors to work through the backlog.

In August 2015, NIST published a Federal Registry Notice seeking public comment on he potential use of certain ISO/IEC standards and crypto module testing, conformance and validation activities.  They did not get much feedback, other than complaints that this was a pay based set of standards.

Question on contractor strategy: we are now getting unusual questions and our labs have to spend time educating the contractors. Request for satisfaction with this strategy. Michael agreed it was  fair point, but that they have smart people.

Note on why they did not receive many comments: questioner said he's on the NIST public list, but the call for comments did not go there, it was only published on the federal register.  NIST noted it was posted to a few places, and asked their labs to reach out.

Question: while it looks like we're moving towards ISO standard, what would happen if we don't get it approved by Secretary of Commerce? Answer: you'd have to wait a loooong time for us to generate something else.

When the new standard is signed, folks will have 12 months to submit under the old standard.

CMVP queue is down from 12 months to 3 months, they are trying to get this down further. Part of the current delay waiting for the cost recovery funds to come in. This can be slow due to large companies' PO process.  Labs can speed this up by requesting the funding from their clients sooner - or possibly NIST needs to bill sooner?  For example, NIST should not wait until the test report is received, but rather send the bill when they are notified that there is a system under test - or some other time before the test report is submitted.

Post by Valerie Fenwick,  syndicated from Security, Beer, Theater and Biking!

ICMC15: SP800-90B: Analysis of Linux /dev/random

Stephan Mueller, Principal Consultant and Evaluator, atsec information security

Not only does Mr. Mueller work at atsec, but he also is a Linux kernel developer in his spare time. 

How do we define the noise sources for /dev/random:

• Disk I/O
• Block device number + 0x100 ||Jiffies || High-Resolution Timer
• Noise derived from access times to spinning platters

•  Human Interface Devices (HID)
•  Interrupts
• fast_pool: 4 32-bit words filled with 
• Jiffies 
• high resolution timer
• IRQ number
•  64 bit Instruction pointer of the CPU.

The output function is a SHA1 hash run over the output and put in the output pool.

How do we condition? The conditioner mixes data into input-pool, a non-approved mechanism according to SP800-90B. LFSR for 128 * 32-bit pool with full rank polynomial.  The goal is for bias reduction. The Disk/HID: bias added due to structure of data to be mixed into input_ool with MSB with rather static data (event numbers), middle bits with low entropy data (jiffies) and LSB with high-entropy data (high resolution timer.

There is a health test, but it is not compliant with SP800-90B.  they measure disk/HID and derivation of event time in jiffies. Minimum of all derivation is estimated entropy of event.  Limitation to 11 bits maximum per event. There is a claim that one bit of input data has less than one bit of entropy.  So, this covers continuous health test requirement and repetition count requirement (even though, again, it's not the test SP800-90B actually asks for).

All of these derivations are applied to all events, including startup - so, we kind of have a start up test.

Interrupts: implicit, without interrupt handling there is no live Linux kernel :-) 

There is no adaptive proportion test - entropy measurement considered equivalent.

The goal of identifying failures is met.

How to observe noise sources and LFSR/input_pool in a live Linux kernel, and unchanged Linux kernel and not ipact entropy calculation - answer: SystemTap! Though Heisenberg's uncertainty still applies, as it's changing timing by adding additional code paths. Akin to executing Linux on a slower system, therefor no impact on entropy estimates. [Note: I'm not sure I agree with that theory.]

Their test results:
General: Chi-Square for IID cannot be calculated and Chi-Square Goodness Fit cannot be calculated. For Disk/HID, only high-resolution timer tested due to main entropy source - other items were zero or close to zero entropy. But, when using lower 11 bits of timer, data is almost IID.  Looking at interrupts, each 32-bit word is tested individually. About half of IID test fail -> non-IID. 

General conditioner of IID: collision tests N/A due to no collisions, and all sanity checks always pass. 

Is the /dev/random on Linux good enough? Noise sources: using the min entorpy values for events and considering the maximum of 11 bits of entropy estimated per event, we pass SP800-90B. Additonal testing beyond SP800-90B shows that more than 6% of events are estimated to have 0 bits of entropy. About 20% of events are estimated to have 1 bit of entropy. Massive underestimation of entropy in noise sources.  For the conditioner: no change from noise sources. With entropy estimator enforced when obtaining random values - preventing random number output when there is too little noise. The passing of the noise source implies passing of the entire random number generator. Other pools feeding /dev/random and /dev/urandom are DRNGs!

Assumption of a certain structure of an entopy source. Straigh data path from noise source to output, and it's difficult to apply to noise sources maintaining an entropy pool

Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: Improved Approaches to Online Health Testing in SP800-90 RNGs

David Johnston, Hardware Security Architect, Intel

There are two basic types of RNGs: big and fast, small and slow.

You need to do online testing to be sure things are actually random, like a statistical test for nondeterministic part. Also need a logic integrity test for the deterministic part : BIST, SCAN, KAT

You can only test for a broken state - strong bias or a strong serial correlation coefficient (SCC).

Min entropy tests are too slow and data hungry to do online. All patterns are equally likely (even all zeros).  But, some patterns are characteristic of a broken state: strong bias or a strong serial correlation coefficient (SCC).

A nice test or "broken - maybe" Note the binomial distribution of short and long patterns in a number of fully random bits. Set bounds for each, then measure each over sample and check they are wall within the bounds. If outside, tag as unhealthy.  The bounds determine the false positive rate.

The advantage - it's cheap. A shift register, 6 comparators and 6 counters.  Spots all repeating patterns up to 6 bits in length and detects bias and correlation. Highly bimodal with stationary data of some bias and auto correlation. Intel CPUs do this over 256 bit samples and aims for 1% false positive.

For an entropy source OHT, what's an error when all patterns are equally likely?

The lower false positive rate means you'll like have a high false negative rate.  how do you know if this is really broken or not?

There's a basic principal: never throw away entropy. - Margaret Salter. If you discard the unhealthy tagged samples, you reduce the entropy. If you accept unhealthy tagged samples, you risk false negatives.  Simple: extract with output = MAC (last_output || MAC(Xi || ... || Xi+r), where n is the number of samples and  is the number of samples that contain the necessary number of healthy tagged samples. Also, mixed in are the unhealthy samples that aren't counted.  Suspicous of MACing over variable field length? See his references (#7).

Over many samples, remember just the 1 bit tag per samples, allos a test over lots of data without huge amounts of memory.  Count the N Healthy:Unhealthy ratio in the last M samples.  Intel CPUS have M=256 -> so the history statistic is over 64Kibit of data..

If it drops below the threshold of goodness, detect and offline.  Ideally, it never happens.

What makes pool feedback good? E.G. Intel's CPUs demand 768 bits of healthy entropy, MACed to 256 its of full entropy, but all intervening unhealthy samples are mixed in, so no entropy is thrown away and occasional false positives don't raise error response.

What's wrong with SP800-90C?

The ENRBG output offers a superset of the DRBG's cryptographic properties. Full entropy vs prediction computational complexity respectively So, a general purpose RNG needs both: DRBG for performance and ENRGBG for arbitrary strength keys and seeding..

The oversampling construction kills performance of DRBG output by forcing intervening reseeds. Unless you put in two DRBGs, doubling the area, doubling the failure rate...

You can add a BIW extractor, and a DRBG for XOR construction.

We wnat better reliability and performance without DRBG. A modern ful entropy ES+Extracot has higher bits/clock/um^2 than an AES-CTR-DRBG.  Best case of 128/10 clocks/31K gate equivalents = 4.13E-4bits per clock per gate (asymptotic as the gen:update ration -> 1.0).

And then we have FIPS 140-2, which has required tests that go beyond SP 800-90A. If you follow 4.9.2, which includes a data modifying test and throwing away data. This yields a radom stream trivially distinguishable from random. No 16 bit equal pairs in 1MByte data = Definitely not random, 16 are expected. It creates algebraic invariates Xi != Xi+1 for all output values, reducing entropy and helping algebraic attacks.

Intel refused to put this in its silicon because it may be a back door. The risk to Intel of having a back door is greater than the cost of not being FIPS compliant.

ISO 19790-2012 removed this test - so, let's hurry up with FIPSf 140-3.

But, still source constrained devices can't have hardware FIPS compliant RNGs because of the DRBG requirement.

Pool structures that use health tagging allow appropriate adaptive responses to entropy source failure and degrdation behaviour and instantaneous response to instantaneous ES failure.

The DRBG requirements of SP800-90C lead to a reduction in reliability and/or efficiency of RNGs and prevent SP800-90 compliant full entropy hardwar RNGs in resource constrained situations. FIPS 140-2 makes this worse.

Johnston has seen systems getting when to block flipped - that is , blocking when they have high entropy and not blocking when their entropy is low.  This is not a good plan, and has led to published papers.

The kernel's job is to do the mixing. While he knows that Intel's entropy source doesn't have a back door, but not everyone else knows that - or know that about their other sources - so, mixing is good.
Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: The Next Steps Toward A Scalable International Cryptographic Evaluation Process

Clint Winebrenner, Technical Lead, Product Certifications Security & Trust Organization, Cisco

How can we work together to eliminate time we're spending doing different validations for different companies. It's not just money to validate against different government standards, but also developer's time.

Is there a reference recommended list of cryptographic algorithms, covering encryption, decryption, etc?

Customers have to trust their vendor to do the right thing, to build software to be secure, safe and comply with RFCs and other standards.  The vendor has to trust the 3rd party test lab.

Trust, but verify. Need to verify that the evidence provided really verifies the algorithms. The testing should be repeatable across all bodies and processes.  It should be scalable, too.

What can we do about remediation? Engage experts from the industry and academia. We need to critically anlyze design from both a security and  performance perspective. Working with academia, industry and government to propose effective and scalable alternatives.

What if you trust the algorithm, but not the validation process?  We can modify existing process for algorithm validation, with methods to verify a sub-set of the effort.  Can we share more evidence?  Why not publish detailed algorithm validation results?

Could this get more complicated?  Yes - we can trust the vendor and the validation process, but not how the algorithm is used. So, we have to look at the protocol's too. Can we share protocol details for all systems under test?

If we can come up with an acceptable international evaluation process, we can have significant savings on time and more reliability.

ICMC15: Effective Cryptography—Or: What's Wrong With All These Crypto APIs?

Thorsten Groetker, CTO, Utimaco

Effective cryptography means it needs to work and be secure, but it also has to get you where you need to go quickly and calculate the results fast 

There are many well known crypto APIS - but there's something wrong with all of the.

PKCS#11 and security issues. There are numerous key extraction attacks known. Jolyon Clulow "on the Security of PKCS#11" and the Tookan project ("Attacking and Fixing PKCS#11 Security Tokens". There are CVE entries as well, but they don't necessarily note PKCS#11.

Why does PKCS#11 have these issues? Confusing sest of mechanisms and attributes - you need automated model checkers to determine secure configurations.  Functions are broken into fine grain operations, which opens the door to eavesdropping and insertion attacks. 

[Note: these are the opinions of the speaker, not my own, as with all my blogs from this conference]

PKCS#11 is not the worst of the bunch. These same attacks can be used against Microsoft CryptoAPI (CAPI), JCE/JCA and Mixed APIs. For example, under JCE/JCA there are wrap-decrypt attacks unless they are prevented by underlying devices. For CAPI, exchange keys can be also used to encrypt/decrypt data to open door to wrap-decrypt attacks.

Efficiency is development cost and time to market. If the team is more comfortable with an API, it will be easier for them to adopt and implement. 

"Simplicity is a prerequisite for reliability." - Edsger Dijkstra. (and hence for security)  Authentication should not be an after thought. We need multi-factor and multi-person (Mout of N) authentication. And don't forget about audit logging!

People tend to underesestimate the cost of data transfers - server -> CSP -> Middleware -> Network Appliance -> Driver -> HSM.  

If you implemented your cryptographic functions as atomic HSM commands it will be faster and more secure.

KMIP is trying to come to the rescue with the concept of batched requests.  This addresses some performance issues, but it is not suited as a general crypto programming paradigm.

Crypto apps running within the secure perimeter of an HSM will become the norm. Drivers include security, eas of use, performance, multi-tenancy, custom logging, portability and cost.  Thorsten believes that firewalling and binding a key to a specific app or device will become a hard requirement.

A PKCS#11 host program will have access to 50+ functions, 200 attributes [XXX - something got lost here - mechs were also mentioned] [Note: I don't believe there is really any PKCS#11 library that implements every mech, every attribute, every functions].

Don't forget how dramatically an easy-to-use API combined with firewalling and enabled 3rd party apps can change an established market. Think about how much things have changed from our old Nokia cell phones with buttons to an Android or iOS phone.

Managed languages make this even easier.

But are people really going to develop embedded apps for HSMs?

Introducing CryptoScript: You eed to write a script, load the signed script (automatically compiled under the hood and executed one where it spawns threads and registers functions as commands), and invoke newly registered CryptoScript commands from the host application in high level languages.

Inside the utimaco HSM there's a boot loader, OS, administrative modules , cryptographic modules and SXI (Cryptographic eXtended services Interface). CryptoScript is on top of all that.

The basic concept is to be small, efficient and portable under the MIT license for easy portability.  The language was pared down by removing application program interfaces, native debug I/F, aux lib and OS facilities. They've enhanced this by adding secure managed memory, command handling, authentication and secure messaging. 

CryptoScript does not allow direct memory addressing and no buffer/stack overflows.

Once you've got CryptoScript Modules - they are loaded in a virtual HSM, so they cannot direct the actual HSM file system and memory.

A question from the audience: If PKCS#11 sucks, due to complexity - how does the problem go away just because we implement it on the HSM?  Answer: the attack vector is removed, CryptoScript has better debugging, and it's faster to develop.
 
Post by Valeie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: Department of Defense Cybersecurity

Marianne Bailey, Principal Director, Deputy CIO for Cybersecurity, Department of Defense

Their main goal: dependable execution in the face of  adversity.  Now everyone is focused on cyber security - at the highest level of security. Bailey is in the white house several times a week to non technical 4 star generals.

Cryptography is critical to the DoD.

Attacks by state and non-state actors are increasing each year, putting all of our assets at risk.  This results in loss of personal data and network outages. Anything with a computer can be attacked. This is not just an IT problem - many things are connected to each other.

We need to establish a culture of cyber discipline - breaches are often human error. Everyone has to understand the risk and must be accountable. Cyber hygiene: configure all computers to DoD standards, make sure every computer is protected, and eliminating the use of passwords by all users and administrators and instead using credentials issued by DoD.

Things haven't been going as fast as they want.  So, really putting alot of effort behind PKI infrastructure to get rid of passwords and role based access control. you can't do two things requiring different levels of privilege at the same time.

We see impersonations, privilege escalation. We have to watch, be aware and be able take action quickly.

Right now, too much of the nation is on the wrong side of these initiatives, which  means the attackers don't have to spend as much money or effort to attack us - but we still have to pay the price afterwards.

Commercial products should be implementing standards based cryptography, and follow other security standards.

Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: Cryptography, Moore’s Law, and Hardware Foundations for Security

Paul Kocher, President, Chief Scientist​, Cryptography Research

While crypto has continued to get better, and protocols have improved - we still are having massive security breaches.   the more complex our code get, the larger the code base gets - we increase our odds of more bugs.  If I have twice as much code, but the same amount of time to look at it, then the odds of missing bugs goes up much faster than linerally.

The Silver Bridge on US 35 in Ohio, built in 1924, collapsed in 1967, due to an engineering issue - gave us the term "fracture critical components".  How many "fracture-critical" elements are in a typical IoT device? DRAM, flash, storage, CPU logic, support logic. We're talking about billions of possible issues.

Our ability to understand simple elements often creates a false impression that we understand the complex system.just because you understand transistors, does not mean you understand a processor, let alone machine language.

We all make a bad assumption: software will be bug-free.  Almost every device you have is 1-3 bugs away from total compromise.Defect densisties re higher than we think.

For side channels, we mistakenly think that attackers only see the binary input/output data - not true! Power and RF measurements show tiny correlations to individual gates. 

Four properties for solutions to succeed. Hardware-based: it's the only layer where we know how to build reliable security boundaries. Deployable additively: legacy designs can't be abandoned, but ar e too complex to fix.  Addres your infrastructure: solutions that must address both in-device capabilities and manufacturing/lifecycle.  Best case: must have a very positive ROI. All stakeholders must benefit, and benefits must not depend on ubiquity.

We need to think about our security perimeters. If you put too much complexity in one boundary, catastrophic failure is more likely. We need to think like the military for how they store their ordnance - if one layer fails, nobody will have all of the munitions.

Software security is not scalable. No hope of eliminating bugs in existing software. CPU modes (like TrustZone, Ring0) haven't helped, despite decades of trying. Separate chips/modules only work for a small subset of uses cases - costly and distant from where security is needed.  He has the most hope fo ron-die security modules. 

Why? High performance, low power. When something is inside the die, it's cheaper to manufacture, lower latency, better performance.

The cost of putting in extra transistors to do security is largely immaterial today - and if you're bothered by it now, just wait 18 months. :-)

Chipmakers required solutions for in-device security and also solutions for enabling infrastructure. Cryptography Research's approach: CryptoManager Solution. Their CryptoManager protects the chip.

If you get twice the code, you aren't getting twice the most desirable features. You added the core features first!  BUT, by adding twice the number of lies of code, you're increasing complexity and adding bugs.

After all of these security breaches, some government agencies in other countries have switched back to the typewriter - it's more secure.

We have to come up with solutions, otherwise security risks will erase net benefits from new technology.  For example, what is the risk vs reward of having your air conditioner connected to Internet. It's great to have the repair automatically called when there is trouble, but does it create an attack vector into your house or office?

All of these security issues means job security for the people in this room, but we should sill try to do beter. :-)

Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!