Saturday, July 1, 2017

Identity Based Encryption

Identity Based Encryption

We were readying the house for visitors and cleaning-up. In the loft, on a bookshelf,  I found a house key. It fit the door to our house, but didn't unlock it.
Where did this key come from? What door does it open? 

It occurred to me that some kind of identifier would help. We've got several keys for other houses and they're all tagged. This key happened to not be tagged. 

This is one aspect of  Identity Based Encryption. With crypto, there are keys. What files, messages, or systems do the keys unlock? The identity is more important than the key itself. 

It's not a stretch to say that a key without an identity is worthless. Indeed, a key under your control without an identity that others would recognize may seem more  secure. The fact that others cannot know what door (file, message, system) it unlocks may be a kind of security. 
But you know what it's for. 

My employer sells "identity based encryption", both asymmetric (IBE) and symmetric (IBSE). It's good stuff. It makes sense. 

This unlabeled house key brings the story to life. Keys need identities so their purpose can be known. 

-- R; <><

Monday, April 24, 2017

NORD and stali

NORD and stali

My friend Skippy sent email suggesting I check out stali. I had seen it before. Good stuff, if perhaps a bit knee-jerk.

Can't help but think that stali springs from a Linux-centric experience, even though the developers clearly value simplicity. And I'm thrilled to see another team fighting the good fight against bloat.

How does it relate (if at all) to NORD?
I took the framework of stali goals and wrote a NORD philosophy (section of the intro doc):

  • Follow the Unix philosophy.
  • Target i386, s390, ppc, and arm hardware.
  • Separate easily-replaced core system from optional packages.
  • Follow Linux FHS where it makes sense.
  • Don’t use SystemD.
  • Make as much static as is reasonable. (minimize shared library dependencies)
  • Achieve simplicity and stability. (good rescue or embedded system)
  • Achieve runs-from-ROM.
  • Minimize security attack surfaces.
  • Include a hand selected collection of the standard tools.
  • Upgrade/install using RSYNC; no package manager needed.

In recent weeks, I needed a clean development system (again!). Had trouble building Squid Proxy on I386. (It built just fine on S390.) So I went about cycling through the core packages (again!), also updated the kernel headers, and tried a re-build of GLIBC. Got stuck. Still stuck. But most things build and re-build just fine.

I've been reviewing some Chicory-built packages to re-do them with static linkage. That will be an ongoing process. 

-- R; <><

Sunday, January 15, 2017

NORD Rationale

NORD Rationale

A few days ago (this is mid January 2017), I added a rationale section to the NORD Linux intro document. I've given a lot of thought to the "why should anyone bother?" question with respect to NORD. The project has become an obsession, but I find objective reasons to continue using it. It's not just a hobby but a tool for other work.

Two systems handling web traffic and other services for are NORD systems. Those are Buckeyes and ltroth1. There are other systems where NORD runs in 'chroot' handling some workloads within that jail. So the environment has become significant within this domain.

Showcase for Other Projects

NORD didn't start out as yet another distro. Projects like simply recompiling the Linux kernel added to a collection. The collection grew into a usable system. It reached critical mass and could sustain real work. That seems to be still its primary purpose. It is the stage where other projects perform.

CSCRATCH is the project which [re]builds the core operating system. It's unique to NORD (though it's not exclusively for Linux). Chicory is more widely effective. Both are just wrappers around the standard recipe.

NORD is my primary platform for hardening activities: reliability, auditability, servicability, as well as penetration defense. There are also growing concerns about trusting trust. (Sure, I'm paranoid. But am I paranoid enough?)

Serious about Source

I've been working with Free and Open Source software for most of my career. At this point, the pay-for and proprietary software that puts food on my table depends inseparably on FOSS. 

Ironically, the rise in use of FOSS throughout the industry has not led to a corresponding use of source code at delivery points. The Linux distributors and forward looking software vendors have done such a good job of embracing FOSS and making it drop-in usable that their customers don't need to actually use the source. But it's tech debt. 

As long as the providers do the right thing, their customers can proceed with their own business and focus on more important details of that operation. And most vendors/distributors are doing the right thing and will likely continue. But take note, be aware, and get ready. Consider source code as part of your business continuity plan. 

NORD can be acquired and used without ever worrying about source or compiling or building. (Compared to "real" distributions it's really rough and I presume the consumer knows traditional Unix.) But NORD is designed to be re-built in a pinch. NORD can assimilate an update or  patch faster than any other Linux implementation. (In recent history was Shell Shock which NORD handled no delays: as soon as patches were available, just recompile.) 

Summary in Three Ss

Rationale for NORD solidifies into simplicity, showcase, and source code. 

Now I need to get others interested. A half dozen friends have lent a hand over the course of this saga. A couple of them have been able to make use of the deliverables. We need more participants. (We at least need people to hammer on the build logic, test the results, find bugs and maybe squash them.) 
Wanna help?

-- R; <><

Sunday, August 21, 2016

The Death of Veracity

The Death of Veracity

Your vocabulary word for today, students, is "veracity". You may notice that Wikipedia re-directs to the page for "honesty". But this post is about a computer, not about moral integrity.

How we came to name the machine "veracity" is a sentimental saga for another season. The soggy sadness of today is the fallout from Veracity (the machine) having silently succumbed to an as-yet unknown hardware failure.

In recent weeks I've gotten a number of alarms "you need to take backups". We seem to have had a rash of machine failures. Veracity's demise is the second outage this week alone. (The other was "the day the WiFi died" which I'll describe in a separate post.)

This is a disaster recovery story, a D/R tail with a happy ending. 

Veracity and Virtualization

The good news is that the systems hosted on veracity appear to be intact. One of them, zechariah by name, is our primary IPv6 gateway server. It is up again, after copying of its system disk and root disk to another virtualization host. Whatever failed on Veracity, thankfully the disk was okay.

The other guest, Jeremiah, followed soon after. It acts as our "main" server (email, files, print, DNS, DHCP). But I had gotten lax about backups. The D/R plan for jeremiah was that if it failed we'd switch the IP address for main over from Jeremiah to Nehemiah. While it lived, Nehemiah contained regular backups of Jeremiah's content. We did switch between the two once or twice in those days.

This method of using a similar-but-not-identical system for failover goes back before we had virtual machines on our little network. Where physical systems are involved, the historical plan for D/R is to have another system with the same or better capability standing ready to pick up the load. I was introduced to virtualization in 1982 but pervasive PC-think prevented me from applying tried and true V12N methods to personal systems. Bummer.

It began to dawn on me that we don't need a secondary server for a virtual system. All we really need is a copy of that system, a clone. Call it replication. Then when disaster strikes, bring up the clone on a designated alternate hypervisor: no moving around of IP addresses, no quirks from the subtle differences between the recovery system and the real system. A copy of a virtual machine is a perfect substitute because it's not actually a substitute. They're more identical than twins. 

Replication and Recovery

Zecharian and Jeremiah are in better shape now than they were before the mishap. The host hardware to which they got moved has KVM. Previously they were Xen guests. Not complaining about Xen, but the change forced me to make some adjustments that had been put off, things that needed to be done anyway. They were already configured to share the O/S (another fun rabbit trail, maybe another blog post). They share a common system disk image, now corrected for KVM. (They each have their own root filesystem.) Once the KVM changes were done for one, the other instantly got the same benefit.

I had more success recovering Zechariah and Jeremiah than with this blog post. (Don't get me started about how the Blogger app likes to lose draft updates.) 

NORD to the Rescue

As it happened, I had a newer kernel for NORD than that of the SUSE release Jeremiah and Zechariah run. As it happened, I already had a KVM-bootable system disk. So I copied NORD's kernel to the SUSE system disk and re-stamped the bootstrap. Generally, one simply brings in the kernel and related modules. As long as the kernel and modules are as-new-as and within the same generation the userland parts should have few problems. Works.

Note: this is a good reason to sym-link /lib/modules to /boot/modules and commit to a replaceable /boot volume It's a feature of NORD but trivial with any Linux distro.

KVM performance sucks relative to that of Xen. Any time you can use para-virtualization (instead of full hardware simulation) you're going to see better performance. Xen was originally para-virt-only and continues to strongly support para-virtualization. But we're using KVM for the sake of manageability. The guests can run with no knowledge of the hypervisor. (We can always switch to para-virt later, selectively per device.) And these guests aren't doing heavy multi-media work. Performance is sufficient. Presence is paramount.

You can see Zechariah for yourself. (You'll need IPv6 to hit it.) The web content is presently unchaged, demonsntrating the effect of a replicated virtual machine. An update with part of this story will be forthcoming. Jeremiah's connectivity is more controlled, not generally reachable from outside.

-- R; <><

Friday, July 1, 2016

misdirected redirection

misdirected redirection

 ... or HTTPS everywhere getting us nowhere

I'm a long time believer in crypto. (Look me up. I'm in the Web-of-Trust.) I've done SSL stack development (in assembler). My day job is helping customers integrate field-level encryption. And I look forward to a safer, more secure, heavily crypto-laden internet.
But I'm concerned about the rush to HTTPS everywhere.

Okay, "getting us nowhere" is an exaggeration, but it makes for a decent sound-alike to English speakers.

To be specific, there are cases where plain HTTP makes more sense. Sometimes it's just for performance sake. Don't presume that every object must be fetched via SSL/TLS. Some content is actually not a security risk. I could ask "Why would you burden not-at-risk clear traffic with encryption?". But I won't ask. To ask would be rhetorical and that would be ASSuming things that might not be correct.

And then there's automation. For better or worse, our world runs on automation, much of which is not encrypted. Not now anyway. Much not now; some not ever. And unencrypted operation is not inherently evil.

Rule number one: don't break stuff.

Instead of rhetorically asking or assuming, I'll tell you: think about what should and should not be protected with TLS/SSL. Don't blindly bloat our treasured traffic with careless crypto. Think. Be selective about which sessions and services actually needs the extra work. (And it will be extra work, and it won't be your burden alone. Choices you make affect other people, always.)

Okay, "don't break stuff" is trumped by security (and by bugs). But hear my point that getting it right is hard work. Blanket solutions aren't solutions, and solving even the most urgent problems by wanton breakage is to follow one problem with another.

It's as if someone (make that plural, many someones) asked (rhetorically), "Why would you not encrypt everything?". The question ASSumes that there's no good reason to have cleartext on the net. But there are good reasons. I'll cite only one because I'm tired, presently annoyed, and generally cranky of late. Here's a classic, "Why would you ever need more than 640K?".

Important note: That's not how the quote goes and Bill Gates never actually said such a thing. (Someone did say something once to John Sculley about floppies being all Apple would ever need in response to a question about Macintosh networking. Wanna guess who?) Please hear my second point that there is no one-size-fits-all for software, or for hardware, or for clothing.

My case is the chicken-and-egg situation of trying to build OpenSSL from source. One must download the source before one can build the source. How does that happen? Easy, use 'curl' or 'wget' or some similar tool, point to, get the tarball. Explode the downloaded tarball and follow the standard recipe. But if you don't have SSL working then you can't use HTTPS.

So far my case doesn't sound like a problem. Here's the problem. Some bright "HTTPS everywhere" aficionado decided that nobody should be using HTTP. When you hit via HTTP you (now) get re-directed to HTTPS. If you're downloading OpenSSL for the sake of implementing OpenSSL ... and you don't already have some kind of SSL or TLS ... this is a difficult situation.

They broke stuff. They broke my stuff. Now it's personal.

Building systems from source is important. Or I don't know, maybe it's not important. (Seems like it's important to some people, but they're getting hard to find.) I build from source for several reasons, partly because I'm a control freak, partly because I'm a tinker, and partly because I don't trust systems built by other people. Trust ... it's always about trust. (Systems built by other people: I do use them, but kind of like Google. I use Google but I don't trust them. Been saying that for several years now. And look, here I am blogging on a Google property.)

The automation in question actually has SSL. The problem is that it has an embryonic infrastructure with an empty PKI trust store. This is not to say that it doesn't have a solid trust chain. It just doesn't (at the point of fetching OpenSSL source) have a cache of root certificates for the World Wide Web. So when we hit a site like (via HTTPS) the server certificate fails to verify. (Plain HTTP is fine, was fine, until mister "my solution works for everyone" did the re-direct re-design on their site.)

Gimme back HTTP!

It's the re-direction that's the problem.
I said HTTP because I meant HTTP. The protocol has 301 and 302. Oy vey, another great feature now fallen victim to abuse by ill-conceived implementation. (There's a long and growing list of those.) The files didn't move. (Would be nice if some people used 301 to replace 404, ya think?)

This is the second time in recent months that I've run up against someone having disabled a perfectly reasonable function because they knew better than the rest of us. I guess we gotta kill stupidity one bad idea at a time.

Let's encrypt. Let's encrypt widely. Let's encrypt carefully.

-- R; <><

Tuesday, June 28, 2016

Off-site Backup

Off-site Backup

I've been pressed for time. Scheduling one thing to finish when another is due to start has become essential. On this particular evening, I was hungry, but needed to walk the dog. So I checked the time required for my pizza: 18 to 21 minutes in the conventional oven. Perfect! I could let this cook while exercising the canine.

As I left the house, it occurred to me that I was leaving the hot oven unattended: wife was visiting family, son was on campus, daughter was at work. The risk was small, but it's the kind of risk that we avoid. I was reminded of what happened to Bdale Garbee a year or three ago.

The Garbee family lost everything. Their home was consumed by the same Colorado fire the rest of us heard about on the nightly news. See the video. Bdale's account is enlightening.

For me, this was just a ten minute mental exercise, but here's how it went. All that was most precious was off-premises: family in distributed locations, dog with me. What remained, except for a few heirlooms, was replaceable. But the data? What if we happened to lose the data? Maybe we depend too much on computers to hold our "data".

Until maybe three months ago, I did have off-site backup. Probably seems like overkill for a residential "data center", but I'm a hobbyist. We hobbyists do things for fun that others do only for pay. Dad was more than happy to let me park a surplus desktop-turned-server at his house. A little Linux, shiny new SATA drive, some SixXS to avoid NAT, and a touch of RSYNC. Voi-la! Instant off-site backup.

That was when he had a house. Now he's in an apartment. The facility doesn't provide wired internet; everything is WiFi. And the hack I had rigged to piggy-back that server off of his Windows box began to fail. (First to go was an old 8-port hub in the Rube Goldberg scheme I concocted.) I retrieved the machine several weeks before my lonesome pizza and puppy party.

Surplus hardware is great! You get extended life (from an investment someone made, if not you yourself) and you get low cost service for all kinds of things. Here I had Fedora with LVM and a decent sized platter stack. It was more than just remote storage; it was also a remote point-of-presence. (Helps for those when-not-if times that something funky is happening with the web. And Netflix can just chill because the bandwidth is way to low for regional masking.)

The point of the post: think about a surplus box built to your own specifications as a means to have your own off-site backup or similar service.

But my off-site machine, and its spinning rust, was back home now. Any catastrophe which might wipe out my primary systems would do just as much to my spare. Scary!

When pooch and I got back from our walk, the house was not in flames. There was no smoke nor out-of-control cookery. Instead I was greeted by the aroma of a nearly finished Red Baron Supreme with thin crust. Yesss!! But I am reminded that I need to get serious about the remote box (or maybe two?) and re-deploy real soon now.

-- R; <><

Sunday, July 12, 2015

Going Dark

Going Dark

Two scary stories made the GMA headlines Thursday morning. The first breaking news was about the coincidental glitches yesterday (knocking down WSJ, halting NYSE, and grounding Continental/United). People, it really could be just a coincidence . (More on that later.) The second nail biter concerned FBI director James Comey's warning: crypto cripples canvassing. I often wonder why I take my cues from ABC, and you would be reasonable to ask "why?". But this was a real story; here's why.

It's called "going dark" when two parties (good or bad) utilize end-to-end encryption. Directory Comey wants a way around it for cases where one of the parties deserves surveillance. A lot of people in my world are doing a facepalm. This is old news. It's the same thing we've heard from the gubmint before. Computer security professionals call it "exceptional access" where a police agency (anyone really) can bypass encryption, somewhat like a traditional wiretap.

When Crypto is Outlawed

It's cliche, but you get the idea. When encryption is outlawed, only outlaws will have encryption. This debate is not new. Techies have been fighting in support of cryptography for decades. If you're not a computer geek, you probably did not know. (If you're not a computer geek, you probably don't *want* to know.)

Today's chilling warning is frustrating: I kind of like Director Comey, but his testimony before congress appears to be without proof.

"Comey didn't offer any evidence regarding FBI investigations thwarted by strong encryption technology. Still, he said, he felt like researchers and tech companies haven't given the government's request a fair shot before dismissing it.  ..."
-- Yahoo news 

I'd like to introduce Mr. Comey to Lynn Wheeler, Bruce Schneier, Jacob Appelbaum, ... and other computer experts. Yes, James, they have given the government's request a lot of thought, and "dismissed" is the wrong word to describe their response. (I know Wheeler personally. Schneier and Appelbaum have high profile reputations in the crypto world, as do Diffie, Rivest, and other contributors to the MIT paper. These people are the best and brightest on this topic.)

When Guns are Outlawed

There's a similar debate about gun control. I have many friends and family who are in the "right to carry" camp. Guns are dangerous, but lots of things are dangerous. My pro-carry peeps get it that the bad guys will have guns. It's better to arm (and train!) the good guys.

Substitute "cryptography" for "guns", or substitute "privacy" there. When guns/crypto/privacy is outlawed only outlaws will have guns/crypto/privacy. The same argument applies (and has yet to be countered) that the bad guys will still have and use guns and crypto even after the law abiding public are disarmed.

The difference (for purpose of analogy) between guns and encryption is that guns are physical and cryptography is mathematics. Any back-door means of bypassing crypto is like an invisible hand on (radio control of) the safety on your Glock. Doesn't matter if the manufacturer swears they'll only ever give that control to legit law enforcement, the mechanism itself is a detriment. Experience has proven time and again that exceptional access leads to unthinkable flaws in the resulting products.

Breaking and Entering

The matter is very personal! I may be damaging my professional reputation by revealing this: I've been hit. It happened a long time ago, and I've learned a lot since then. Someone broke in to one of my computers. Was I surprised, scared? Heck yeah! So I did some forensics and I'm confident about the extent of the breach and have worked hard to keep things secure going forward.

Do I want strong encryption? You betcha!!

But a back door? No way! The front door is enough trouble to guard, thank you.

The FBI wants back doors in the apps and systems (phones). By analogy, these apps and smart phones are akin to a house with cheap siding, too many windows, and no Tyvek. They don't even need the barrel of a tank turret to pierce the wall, just kick it. In other words, the infrastructure surrounding two end-to-end encrypted devices is fully exposed and easily watched.

Good Morning America

It was a GMA headline that jolted me awake. (Coffee had not kicked in yet.) Whether ABC, CBS, NBC, Fox, CNN, ... attention grabbing headlines sell. There's no way "you" are going to get the straight scoop about crypto tech from a major news outlet. It's not in their best interest to give you the full fair-and-balanced story. (Not even Fox, much as they tout that slogan.) If you want to really understand, you may have to do some journalistic gymnastics of your own.

Balanced against the consumerism of ABC is an article on Huffington Post. Not my favorite rag by a long shot (and the author supports "IP enforcement" raising an eyebrow), but truth is truth and Ms Espinel got this one right: back doors weaken defenses.

Good Grief America!

Being a software guy, with decades of experience in encryption, I knew the GMA story told only the most seductive fraction. Director Comey would do better to mute some of the conversation he wants to start. It's not in our best interest to be arguing details in the news media where terrorists can watch.

The fact is, even when a bad guy scrambles the message, he still leaves tracks. Maybe my homey Comey should pal-up with the NSA. Whether they can un-scramble the eggs or not, they're the first people he should ask how-to. The exposed infrastructure (mentioned above) is leaking info all over the place. Google knows it. Apple knows it. The NSA and CIA know it. Chances are the FBI knows it too.

Everyone (not just FBI): quit looking for short-cuts.
Going dark does not make the parties invisible, just opaque. 
Arm the law abiding majority, including the cops, and get busy with actual police work to stop the criminals.

-- R; <><