Comparison of .NET and Java Security


Denis Piliptchouk has written a four part series comparing .NET and Java security on O’Reilly’s OnJava site.



  1. Part 1 – Security Configuration and Code Containment
  2. Part 2 – Cryptography and Communication
  3. Part 3 – Code Protection and CAS
  4. Part 4 – Authentication and User Access Security

Overall, Denis finds that CAS is a much better system than Java’s equivilant system, although he does think that Java is more easily extensible.  He thinks that Java’s X509 certificate class is much better than .NET’s X509Certificate (which will be rectified with the upcoming Whidbey X509CertificateEx class), but overall the two cryptography systems are about equal, with Java having a slightly more complex class hierarchy due to their initial structuring around United States export restrictions.


Denis also finds that .NET is much better for security when it comes to web services, since Java doesn’t even provide a solution there, although he points out that security and remoting in .NET is not up to par.  (Though Microsoft does provide several example implementations of creating a secure sink for remoting).  In terms of verification, Denis thinks that both platforms do a good job, although .NET does provide more checks and an easier environment to use.


One area where I disagree with his article is when he says that every assembly should be signed with a different strong name.  I tend to think that all assemblies from one company (or one product) should be signed with the same key, making CAS policy easier to setup.  For instance, if I know that I’m always going to trust code from Adobe, and they have one company key, it’s very easy for me to add a custom code group providing full trust to that key.  However, if they use a different key for every assembly, I’m going to have to add many extra code groups.  The problem gets worse if there are new assemblies in the next version of their product; possibly causing SecurityExceptions after the upgrade, since these new assemblies will not be trusted at the same level as the rest of the application.


Updated: (2/27/04) Added the link to the recently posted part 4.

Comments (5)

  1. Denis Piliptchouk says:

    A comment from the author:

    What you’re disagreeing about is actually addressed via different mechanism – .NET does support publisher’s certificates, and they behave exactly as you are expecting.

    As for the strong names – they’re cryptographically strong variants of usual file names, which makes them unique in the global space. In order to preserve this uniqueness you have to create a new keypair for each separate assembly – much like a SSN unambiguosly defines any person in US.

  2. Shawn says:

    While I agree that publisher certificates do solve the problem I mention, there are two drawbacks to relying on them.

    1. They cost money to get — individual developers and hobbyists tend to not have certificates, and use .snk files to sign their assemblies. I may want to just trust everything someone has written, I wouldn’t want to trust each assembly seperatly.

    2. They expire, which means that I would again have to setup a new code group for each publisher every so often. This may not be the biggest pain, however it will over time lead to a large mess of code groups in my policy.

    That being said, using certificates is a viable solution, especially for my Adobe example, and not one that I have any problem with. Also, when ClickOnce ships and becomes more pervasive, this problem will go away (since ClickOnce will manage trust decisions on a per-app basis, and I won’t have to manually trust each assembly in an application).

  3. Ryan M, Hurst says:

    In Longhorn, windows will have better support for peer-trust scenarios based on X.509 and publisher signing will be no exception to this rule; technically today its possible to do this but the user experience and toolset around doing so, well leaves a lot to be desired.

    Heres the thing on strong names though, they were designed to be a component name not a publisher name; when you start to use the same name for every component you start to run into problems; particularly at larger companies.

    One example I like to give to this problem is messenger, as it has changed product group hands a number of times at Microsoft; at one point it was part of MSN, at another it was part of IE, and at another it was part of Windows. The servicing story for the components gets "hinky" if only one key was used.

    Another reason its bad is DLL hell, thats one of the core issues that was being addressed by strong names right? well one of the issue with that problem set was that even Office would "slam" hinkey versions of system binaries down during their installs resulting in system instability. Having unique keys per components helps address this problem too.

    Also once your talking phsical identity theres a bunch of things you need to start woring about, like when was the signature applied (time-stamping), how was this identitify verified, is there a mechanism to identify faults in the verification process (revocation), what about effective key length, how long should I beleive this key represents Adobe, etc. Authenticode (publisher signing) addresses these problems, strong names do not.

    In summary its my option that every component should have a unique strong name, and every application as defined by its application/click-once manifest should have atleast a one identity signature if not more; these include:

    publisher signature – I am the author, I call this thing acrobat, it opens pdf files.

    certifier signature – I am a certification entity, I have verified this thing meets bar y

    deployer signature – I am someone who deploys software (IT), this thing meets criteria x and if you trust me to attest criteria x you should be ok to run this.

    My .02c

    Ryan M. Hurst

  4. It’s been a while since I’ve last seen a comparison of Java and .NET security.  Nathaneal Paul and…