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?

CSIS Report:Securing Cyberspace for the 44th Presidency

The Center for Strategic and International Studies (CSIS) provides strategic insights and policy solutions to decisionmakers in government, international institutions, the private sector, and civil society. A bipartisan, nonprofit organization headquartered in Washington, DC, CSIS conducts research and analysis and develops policy initiatives that look into the future and anticipate change.

http://www.csis.org/component/option,com_csis_pubs/task,view/id,5157/

Experts : James Andrew Lewis

Synopsis:
The CSIS Commission on Cybersecurity for the 44th Presidency has released its final report, "Securing Cyberspace for the 44th Presidency." The Commission’s three major findings are:

1. Cybersecurity is now one of the major national security problems facing the United States;
2. Decisions and actions must respect American values related to privacy and civil liberties; and
3. Only a comprehensive national security strategy that embraces both the domestic and international aspects of cybersecurity will improve the situation.

Rep. Michael Mccaul, who co-chaired the work has an open letter here:
Congressman McCaul Unveils Cybersecurity Recommendations to the 44th President

Federated Identity Support with JBoss

People ask me the following questions:
* when are we getting SAML support in JBoss?
* when will we get a formal identity management solution for JBoss community and enterprise users?

For a while, I have been deferring answering this basically to first get a clear picture of the stabilization of the federated identity space. In addition, we had the great JBoss Application Server v5.0 to be sent out of the door with great security features.

Given this, what are our plans?

JBoss Identity:
Various projects under the JBoss umbrella have gotten together with stakeholders and formed this project called as "JBoss Identity". JBoss Application Server, JBoss Portal, JBoss SOA, JBoss Rules/Drools, JBoss Seam etc will all utilize the work from this common project.

Results Desired:
JBoss Identity Management (Management of Users, roles etc) for a single domain
JBoss Identity Federation (Allow support for federated identity standards)

Design: http://www.jboss.com/index.html?module=bb&op=viewforum&f=284
JIRA: https://jira.jboss.org/jira/browse/JBID

Going forward, we want to support the following standards from a federated identity perspective:

1) SAML v2.0
2) WS-Trust
3) Liberty ID-WSF

These 3 standards are important for the JBoss SOA Platform.

Roadmap:
JBoss Identity Federation v1.0.0 (February 28, 2009)

SAMLv2.0

SAML core Structures
Web Browser SSO Profile
- HTTP/Redirect Binding - Jan 15, 2009 (with Signature support)
- HTTP/Post Binding - Feb 15, 2009 (With Signature support)

WS-Trust (Parallel work with SAML)


JBoss Identity Federation v1.1.0 (May 31, 2009)
SAML v2.0
- Encryption Support to Web Browser SSO Profile
- Identity Provider Discovery Profile

Liberty ID-WSF

Note: These dates are subject to change.


Challenges: It takes years (if not close to a decade) to actually get a fully compliant federated identity management solution. There are a lot of issues involved - testing, complex configuration, complex diverse requirements etc. So, we will follow the path of least resistance - listen to our users as to what their needs are.

* We have to make the system very simple to configure (of course we should assume reasonable defaults). No point in piling on to the configuration headache associated with security.
* We will allow the system to work with the great container security (JBoss/Tomcat). Why reinvent the wheel?

How can you help?
Please use the following thread to talk to us with use cases etc and be early adopters of out technology.
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196628

Events:
JBoss Identity will be put to test at the Oasis XSPA Interoperability event at HIMSS 2009 in April 2009 at Chicago. We will use SAML v2.0, XACML v2.0 and WS-Trust applied to use cases in the health care sector.

Vision: JBoss Identity along with Identity Federation, supplemented with JBoss XACML, will enable federated identity as well as federated authorization support for the community.

JBoss AS 5.0 and Security

As you may already noticed, JBoss Application Server v5.0 was released a week ago. It is a Java EE 5.0 certified application server as shown from the compatibility page at JavaEE Compatibility.

JBoss AS 5 has many security enhancements that the community will benefit from.

Apart from the JBoss Microcontainer integration, the security layer has pluggable authorization stacks, auditing and simplified configuration.

To achieve the highest form of security for your applications running on the JBoss Application Server, it is recommended to run the application server under a Java Security Manager. You can configure your permissions assigned to your applications using the following security manager policy as a template.

http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_5_0_0_GA/testsuite/src/resources/securitymgr/server.policy

Look for my blog posts on JBossAS5 security here.

AS5: Fine Grained Authorization using Oasis XACML (Part 1)

Access Control is one of my favourite topics in security. There are two aspects to it - coarse grained and fine grained access control. The JavaEE specifications typically mandate container based authorization which tend to be coarse grained.

For Web Applications, there is enforcement on web resources (via URLs) using roles. The beauty of container based security is that user applications can delegate authentication, authorization and auditing to the container.

But coarse grained authorization may not solve all user applications' access control needs. You may have some fine grained use cases or context based use cases such as the following:

"Allow access to this part of the web applications for users who are 18 years and older"
"Only managers can update the payroll of their subordinates"
"Allow access to this section of the web application to users who are employed, accessing from the US, between 9am-5pm on Monday-Thursday"

These cannot be catered to by the access control mechanism in the Servlet specification, for example. You can turn off container security and try to do this yourself via servlet filters. What is the problem in doing this? Each time the requirements change, you have a code change.

How nice will it be if you could externalize the policy infrastructure from your code? JACC does do it with PolicyConfiguration etc. But it is not as extensive as Oasis XACML specification.

The great thing about Oasis XACML specification is that it is totally tailored towards access control and IT DOES NOTHING ELSE. It defines a language and structures to define your policies/rules and an architecture for a decision point (aka Policy Decision Point, PDP) and one or more Policy Enforcement Points (PEPs).

I am sure you can google XACML and learn more about it.

The good news is that JBoss Application Server v5.0 bundles JBossXACML v2.0.2.SP1. What does this mean? It means that you now have capabilities to extend your container authorization mechanism to include XACML policies shipped with your web/ejb deployments. Apart from this, if you need to do your own security work in your applications and looking for a XACML stack, then you can use the friendly JBossXACML api to create policies, do evaluations etc.

Please wait for Part 2 of this post to read more about using XACML for your web and ejb container authorization.

AS5 : Pluggable Access Control - EJB/Web

The key driver for security for Java EE components such as Web or EJB Components in JBoss Application Server is the concept of a 'security domain'. The security domain is an abstract concept that defines the authentiation, authorization, audit, mapping etc. modules in JBoss Application Server 5.

An user may need to make access control stacks pluggable for a particular component.

You can continue to configure your security domain name in jboss.xml (ejb) or jboss-web.xml (web) deployment descriptors. But there are multiple ways to configure your authorization modules that govern your web and/or ejb components.

1) Change the default authorization policy for all web/ejb components. You can do that by changing the "jboss-web-policy" and "jboss-ejb-policy" in deploy/security/security-policies-jboss-beans.xml

An example is here:
http://anonsvn.jboss.org/repos/jbossas/trunk/testsuite/src/resources/test-configs/jacc/deploy/security/security-policies-jboss-beans.xml

If you want to retain the normal authorization stack (do not care about JACC, XACML or custom authorization), then make no change and stop reading this blog entry. :)

2) You wish to change the authorization stack for a particular component. Lets say, test.war which has a security domain of "test-domain".

To configure JACC as the authorization stack, either in conf/login-config.xml or in a separate test-war-jboss-beans.xml (the file name should be xxx-jboss-beans.xml where xxx can be anything you desire), define the following.

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns="urn:jboss:bean-deployer:2.0">

   <application-policy xmlns="urn:jboss:security-beans:1.0" name="test-domain">
     <authentication>
        <login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule"
            flag = "required">
            <module-option name = "unauthenticatedIdentity">anonymous</module-option>
            <module-option name="usersProperties">u.properties</module-option>
            <module-option name="rolesProperties">r.properties</module-option>
         </login-module>
      </authentication>
      <authorization>
         <policy-module code="org.jboss.security.authorization.modules.JACCAuthorizationModule" flag="required"/>
      </authorization>
   </application-policy>  

   <application-policy xmlns="urn:jboss:security-beans:1.0" name="test-domain2" extends="other"> 
      <authorization>
         <policy-module code="org.jboss.security.authorization.modules.XACMLAuthorizationModule" flag="required"/>
      </authorization>
   </application-policy>  

</deployment>

What we have done here is that we have defined "test-domain" to have JACC and test-domain2 to have the same authentication modules as "other" but we have used XACML as the access control stack.

FAQ:
1) What happens when some security domains do not define any authorization modules?
A. In this case, the authorization modules defined in "jboss-web-policy" or "jboss-ejb-policy" in deploy/security/security-policies-jboss-beans.xml kick in.

2) Can I stack access control modes for a particular security domain?
A. Yes, you can use the JAAS way of stacking the authorization modules and also use the flag required,requisite,sufficient, optional} to influence the final decision.

<application-policy xmlns="urn:jboss:security-beans:1.0" name="some-domain">
     <authentication>
        <login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule"
            flag = "required">
            <module-option name = "unauthenticatedIdentity">anonymous</module-option>
            <module-option name="usersProperties">u.properties</module-option>
            <module-option name="rolesProperties">r.properties</module-option>
         </login-module>
      </authentication>
      <authorization>
         <policy-module code="org.jboss.security.authorization.modules.JACCAuthorizationModule" flag="required"/>
         <policy-module code="org.jboss.security.authorization.modules.XACMLAuthorizationModule" flag="optional"/>
      </authorization>
   </application-policy> 

3) What about other components such as Messaging, JCA etc?
A. Patience. We will get there eventually. JACC is not defined for other components. While you can use XACML or write your own custom authorization provider, we have not yet provided the pluggable access control feature for components other than web and ejb. We will get there.

4) I would like to write my own authorization provider. What do I do?
A. What you need to write is a policy module such as the ones we have.
http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/tags/2.0.2.SP3/jbosssx/src/main/java/org/jboss/security/authorization/modules/

5) I know that authentication is not tied to any layer such as web, ejb etc; but authorization is always tied to the type of component we are guarding. Your examples do not show it.
A. We respect your smartness. You should start contributing to JBoss Security. We have the concept of delegates within the authorization modules. You can do something like this:

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns="urn:jboss:bean-deployer:2.0">
 

   <application-policy xmlns="urn:jboss:security-beans:1.0" name="test-domain2" extends="other"> 
      <authorization>
         <policy-module code="xxx.yyy.MyAwesomeAuthorizationModule" flag="required">
           <module-option name="delegateMap">web=xxxx.yy.mywebauthorizationdelegate,ejb=xxxx.yy.myejbauthorizationdelegate</module-option>
         </policy-module>
      </authorization>
   </application-policy>  

</deployment>

Remember, that your delegates need to be a subclass of AuthorizationModuleDelegate.
http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/tags/2.0.2.SP3/jbosssx/src/main/java/org/jboss/security/authorization/modules/AuthorizationModuleDelegate.java

Examples are:
http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/tags/2.0.2.SP3/jbosssx/src/main/java/org/jboss/security/authorization/modules/ejb/EJBJACCPolicyModuleDelegate.java

http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/tags/2.0.2.SP3/jbosssx/src/main/java/org/jboss/security/authorization/modules/web/WebJACCPolicyModuleDelegate.java


Read the post here: http://anil-identity.blogspot.com/2008/12/as5-pluggable-access-control-ejbweb.html