Live data from Hacker News

Verified Correctness and Security of OpenSSL HMAC

katherineye.com

11–20 of 27 posts

Re: Verified Correctness and Security of OpenSSL HMAC

#11
post #8
post #6

Earlier quoted context omitted.

It's not really a 'bit beyond'. The proof is about the machine code that runs on the CPU! It's a huge abstraction gap from C and it is the result of years of formal proofs and PL research. About the effort being worth it or not, I believe that security critical programs MUST have formal proofs. Vulnerabilities in this kind of software are extremely costly. The same goes for software whose failure can be of danger for…

A surprisingly large number of lines of code become security critical by dint of inclusion in security critical systems designed by others, or in support systems for those critical systems.

...which is a big reason why I find it insane that people aren't more interested in microkernel (or unikernel+hypervisor, which ends up in the same place) designs.

If you can have a tiny trust-kernel that has been proof-checked, keep everything else outside of it, and the things outside of it can only communicate with (or even observe) their peers via messages sent through it, then you don't need to worry about including untrusted code in your app.

Instead, you just slap any and all untrusted code into microservices (microdaemons?) in their own security domains/sandboxes/VMs/whatever, and speak to them over the kernel's message bus (or in the VM case, a virtual network), and suddenly they can't hurt you any more.

Re: Verified Correctness and Security of OpenSSL HMAC

#13
post #11
post #8

Earlier quoted context omitted.

A surprisingly large number of lines of code become security critical by dint of inclusion in security critical systems designed by others, or in support systems for those critical systems.

...which is a big reason why I find it insane that people aren't more interested in microkernel (or unikernel+hypervisor, which ends up in the same place) designs. If you can have a tiny trust-kernel that has been proof-checked, keep everything else outside of it, and the things outside of it can only communicate with (or even observe) their peers via messages sent through it, then you don't need to worry about inclu…

Do you have any examples of this type of approach being used in any projects? I'd be curious to check out how it works code-wise.

Re: Verified Correctness and Security of OpenSSL HMAC

#14
post #11
post #8

Earlier quoted context omitted.

A surprisingly large number of lines of code become security critical by dint of inclusion in security critical systems designed by others, or in support systems for those critical systems.

...which is a big reason why I find it insane that people aren't more interested in microkernel (or unikernel+hypervisor, which ends up in the same place) designs. If you can have a tiny trust-kernel that has been proof-checked, keep everything else outside of it, and the things outside of it can only communicate with (or even observe) their peers via messages sent through it, then you don't need to worry about inclu…

I think the problem is that operating systems aren't that useful until they have applications and a userbase. Some projects (like Mirage[1] and a few others) try to get around this by building on top of Xen, but that creates a lot of friction.

[1]: http://openmirage.org/

Re: Verified Correctness and Security of OpenSSL HMAC

#15
post #6

I always find these sorts of things interesting and research in this area is something I try to pay attention to whenever it comes to my attention, for example here is another recent paper about verifying curve25519 http://dl.acm.org/citation.cfm?id=2660370 . However, it seems that there is a tremendous amount of effort that goes into proving this software and I wonder if the time investment makes sense. Humans are p…

It's not really a 'bit beyond'. The proof is about the machine code that runs on the CPU! It's a huge abstraction gap from C and it is the result of years of formal proofs and PL research. About the effort being worth it or not, I believe that security critical programs MUST have formal proofs. Vulnerabilities in this kind of software are extremely costly. The same goes for software whose failure can be of danger for…

Too be fair it looks like they're "just" using CompCert to go from C to asm. CompCert has been around for a while and is a verified compiler, which itself is quite an accomplishment.

But yes, it is remarkable how far things have come with regards to formal methods. But it is still quite tedious to do unless you're an academic working in the field.

Re: Verified Correctness and Security of OpenSSL HMAC

#16
post #6

Earlier quoted context omitted.

It's not really a 'bit beyond'. The proof is about the machine code that runs on the CPU! It's a huge abstraction gap from C and it is the result of years of formal proofs and PL research. About the effort being worth it or not, I believe that security critical programs MUST have formal proofs. Vulnerabilities in this kind of software are extremely costly. The same goes for software whose failure can be of danger for…

Too be fair it looks like they're "just" using CompCert to go from C to asm. CompCert has been around for a while and is a verified compiler, which itself is quite an accomplishment. But yes, it is remarkable how far things have come with regards to formal methods. But it is still quite tedious to do unless you're an academic working in the field.

I know the project quite well, it's led by Appel and is called Verified Software Toolchain. They not only compile their code with compcert but also use its correctness theorem to derive the validity of the Assembly code!

Re: Verified Correctness and Security of OpenSSL HMAC

#18
Three gripes I have with many formal methods projects are (a) choose something about useless to prove, (b) reinvent the wheel unnecessarily, and (c) an assurance argument with huge gaps or on a knockoff of the actual problem. I like that this project does the opposite in each area: a useful algorithm implementation whose proof build on other's projects with end-to-end assurance. Wise. I look forward to reading the paper.

So, what to do next. I suggest working on stuff that isn't getting much attention. For security, realistic proofs are lacking of useful protocols and crypto-constructions from requirements to design to implementation. Also, much foundational software builds on libraries implementing ZIP, PNG, reg ex's, and so on. More verification of those has widespread effect. Program transformations, optimizations of CompCert, integration of covert channel analysis into such tools, more static/dynamic checking, assemblers/linkers, and so on could all use more verification work done with the nice qualities I mentioned about this one. So, any readers thinking of a project might consider the above. That said, it would be nice if this could benefit the average person without formal methods abilities, right?

I thought hard on it. Our systems stuff is usually coded in low-level, imperative languages for performance. Our high assurance work often uses functional programming (or functional style) for specs, tools, and so on. Yet, the limitations and TCB's of those in systems space are huge obstacles. Yet, old Scheme/LISP work showed how to turn a limited functional program into an imperative one step by step by fleshing out its state (among other things). We've also seen metaprogramming & MDD techniques allow us to specify something at a high level with low-level, fast code automatically generated for the target.

I think the trick is to combine all of this: subset of functional programming specifies high-level operation of program and low-level operation of target language (esp fast parts); verification of useful primitives (eg stacks, pointer arithmetic) with high-level interfaces macro-style; a coding style + methodology for going from high functional to low imperative; verified transformations for optimization, macro expansion, and code generation. Each of these exist in some form, most verified in some way. What's left is to verify all of them and their integration. Such an integrated approach might dramatically simplify verification of software by letting developers simply describe it in a high-level, functional way with a step-by-step process to deployment. Verification, depending on talent, might range from manual inspection to machine-checked proofs. Yet, doing it this way should be much easier than converting them to formal verification experts.

What do you developers or formal methods people think of this?

Re: Verified Correctness and Security of OpenSSL HMAC

#19

I always find these sorts of things interesting and research in this area is something I try to pay attention to whenever it comes to my attention, for example here is another recent paper about verifying curve25519 http://dl.acm.org/citation.cfm?id=2660370 . However, it seems that there is a tremendous amount of effort that goes into proving this software and I wonder if the time investment makes sense. Humans are p…

My main comment addresses some of this. I think the consensus on this is that most software will use other techniques with lower barrier to entry that leverage stuff built with higher assurance. For example, certain imperative (Ada) and functional (Ocaml) seem to prevent all kinds of errors with decent performance. The Middle Way is to make the toolchain and critical libraries high assurance while the developer uses the basic features of the language with a decent software process. The process aims for good requirements, conservative design, reuse of proven implementation strategies, and good coding styles. These get checked, analyzed, and turned into machine code by trustworthy components.

Such an approach knocks out the vast majority of problems. The rest get squeezed out incrementally over time as research and development continues.

Re: Verified Correctness and Security of OpenSSL HMAC

#20
post #13
post #11

Earlier quoted context omitted.

...which is a big reason why I find it insane that people aren't more interested in microkernel (or unikernel+hypervisor, which ends up in the same place) designs. If you can have a tiny trust-kernel that has been proof-checked, keep everything else outside of it, and the things outside of it can only communicate with (or even observe) their peers via messages sent through it, then you don't need to worry about inclu…

Do you have any examples of this type of approach being used in any projects? I'd be curious to check out how it works code-wise.

I link to quite a few microkernel-based examples in the recent post below. Skip to my reply to @Thoth with all the links.

https://www.schneier.com/blog/archives/2015/05/friday_squid_...

Post reply on HN