Dr.Ron Rivest on Computer Security and Cryptography

Dr. Dobbs Journal has posted a transcript of an interview with Dr.Ron Rivest from 1997. He talks about Computer Security and Cryptography. Even though the interview is dated - the concepts, concerns etc. remain the same.

You can find the interview here.

Some important comments from Dr.Rivest.

In general, security consists of implementing the policies of someone who designed the system, policies regarding who should have access to, and who should control, various kinds of information.

.. probably safer using their credit card for Internet transactions than they are using it in a local restaurant. It's much easier for the clerk with a credit card slip to make off with your number than it is for someone to mount a sophisticated attack against an encrypted Internet line.

With electronic voting, you can tell that your vote has been counted.

MD5 is considered harmful

Message Digest Algorithm 5 (aka MD5) was invented by Ronald Rivest in 1991 as a replacement to the insecure MD4 algorithm. But current research has shown that MD5 is insecure, due to "collisions".

Source: http://www.win.tue.nl/hashclash/rogue-ca/

MD5 considered harmful today : Creating a rogue CA certificate
dated December 30, 2008

Authors: Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger

We have identified a vulnerability in the Internet Public Key Infrastructure (PKI) used to issue digital certificates for secure websites. As a proof of concept we executed a practical attack scenario and successfully created a rogue Certification Authority (CA) certificate trusted by all common web browsers. This certificate allows us to impersonate any website on the Internet, including banking and e-commerce sites secured using the HTTPS protocol.

Our attack takes advantage of a weakness in the MD5 cryptographic hash function that allows the construction of different messages with the same MD5 hash. This is known as an MD5 "collision". Previous work on MD5 collisions between 2004 and 2007 showed that the use of this hash function in digital signatures can lead to theoretical attack scenarios. Our current work proves that at least one attack scenario can be exploited in practice, thus exposing the security infrastructure of the web to realistic threats.

An active discussion on this issue is happening at http://www.ietf.org/mail-archive/web/saag/current/msg02348.html

Additionally, US-CERT has issued an advisory.

Read More.

Java CodeSource Based Security Model

We have shipped JBoss Application Server v5.0 based on VFS (Virtual File System) semantics in the microcontainer. To get the Application Server to run under a Java Security Manager while trying to retain the default policy implementation in the JDK, I went through a lot of troubling times as evident from this design forum thread. There was a lot of finger pointing, crying and swearing in public involved. Equally there were enough emails flying across in internal mailing list(s) with the designers of the JBoss microcontainer.

Well some of the issues are being described by my friend, Dennis Pilipchuck (Enterprise Security Architect at BEA/Oracle) in his java.net article titled:
"Pitfalls of the Java Permissions Model"

========================================================================================

Pitfalls of the Java Permissions Model by Denis Pilipchuk -- Is Java a good choice for creating applications with configurable security? Denis Pilipchuk argues that Java's permissions-based security model is a relic of its browser days and lacks the configurability, expressiveness, and efficiency that enterprise Java developers need. In this article, he looks at the problems of the permissions model and considers some alternatives.

===========================================================================

The CodeSource URL based Java Security Model is outdated. It has never been updated since the browser-applet security days. Li Gong architected the model, then moved to Microsoft and then eventually to Mozilla Foundation (his journey has taken a decade - but the Java permissions model has neither seen any updates nor seen any desire for alternatives). So this article from Dennis seems like a coincidence in blessing. So we are not alone.

We were able to ship JBoss Application Server v5.0.0.GA to run under a security manager with the following security manager policy as a template.
Java Security Manager Policy

What were our options?
a) Write a new policy provider - this would mean a new configuration format for the permissions and would actually shoo away any rare souls who want to run the application server under a security manager.
b) Try to somehow get the default jdk policy provider to recognize or tolerate vfs urls. We ended up with this option of having dummy URL protocol handlers in the JBoss AS bootstrap and at the time of policy enforcement, we would get the real vfs codesource urls read in as the vfs protocol handlers were in place.
c) Update the VFSClassLoaderPolicy implementation to return real urls of the code jars rather than the vfs urls. We do this now by default. It avoids the issues we had with the default policyfile implementation not understanding vfs urls. But we have kind of disabled the superior vfs urls for consideration by the security manager.

Complaints with the Java Permissions based Security Model:
1) CodeSource takes an URL instance and not URI.
2) No negative permissions that can be declaratively defined (Dennis talks about this too). JACC 1.1 has a work around in the actions of WebResourcePermission for "excluded" security constraints with a "!" prefix.
3) Stack frame checking across the call path is performance intensive. Privileged blocks in the source code mitigate the walking penalties but are so poorly understood (or avoided) by developers that an introduction can accidently be the source of security holes.

We really need updates to the Java Policy class/interface with alternative mechanisms and a need to foster usage of policy.implies (after the alternatives have been identified) in the enterprise source code before embarking on sensitive operations such as using reflection, getting the classloader etc.

I wonder about the following:
a) How many enterprise deployments run under a Java Security Manager? If not, without explicit policy.implies checks, everything is open.
b) How well Java privileged blocks are understood and adopted by enterprise developers and Framework writers?

JBoss portal previously attempted to define their access model based on JACC. They had to define their own permission classes and got it working. The developers found it extremely cumbersome. Currently they are working on adopting an XACML based approach using JBossXACML. In JBoss AS5, we provide a pluggable access control model where in you can plug and play access control stacks based on JACC, XACML or your custom implementation.

Related References:
Ted Neward's White Paper: http://www.tedneward.com/files/Papers/JavaPolicy/JavaPolicy.pdf

Additionally, improving the Java Security Model is not the responsibility of Sun alone. It has to be pushed for by the other VM vendors (IBM, BEA/JRockit etc) also. Maybe Dennis can ping his own JRockit folks?