Wrote about Microsoft Windows XP Starter Edition at Econotrix
While on Windows I swear by Firefox. I have always kept falling back to Safari on my Mac, because it seems faster. Seeing that they moved to CFRunLoop (whatever that is) on the trunk I thought I’d better try it out.
I am using one of the G4 optimized builds from KRMathis and it is absolutely screaming. I did briefly test the built in SVG viewer as well, which seems cool, but I guess it will be a few months before we see a really good use of that.
Anyway if you want it fast get the nightly build.
Unfortunately they are not possible yet. I was just googling to see if there was any info on it.
It turns out that there is a a new project going to implement H324M for Asterisk . This would be insanely cool.
We are a dual 3G phone household, but my Nokia 6630 insanely has only a back facing camera, so it is pretty much pointless using it. However with something like this H324M project I could use that part of my phone for various interesting internet based projects.
Wow XML Signatures for everyone. JSR105 was just released as the new standard api for Java applications requiring XML Signature support.
The only problem is that the XML Signature library has major security flaws and almost all the libraries that are out there including JSR105 do absolutely nothing to address them.
Firstly neither the XML Signature standard nor the JSR105 are technically flawed. Nay, the major security flaw here is in the usability and awful complexity of the two standards.
The dangerous reference processing model
The XML Signature standard was designed to create and verify all matter of signatures using XML. The stuff signed doesn’t have to be XML. It could be the contents of a URI. Some specified external object, some Xpath transformed fragment of a xml document. What have you. The Reference Processing Model is extremely flexible and therein lies the standards number one threat.
Where is the threat? The threat is one of usability. I would say that most people who use XML Signature libraries are not experts in the standard. Rather they use off the shelf libraries, such as the JCP105 or Apaches XML Security.
To Illustrate my point I will give you to examples that look very similar to the human reader as well as the naive XML Signature API implementation:
What is signed here?
This a standard Enveloped XML Signature:
<Payment xmlns="http://payme.not">
<payee>pelle@neubia.com</payee>
<amount>1000</amount>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" />
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>fdy6S2NLpnT4fMdokUHSHsmpcvo=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
Z4pBb+o+XOKWME7CpLyXuNqyIYdXOcGvthfUf+ZDLL5immPx+3tK8Q==
</SignatureValue>
<KeyInfo>
cut for space constraints
</KeyInfo>
</Signature>
</Payment>Which is the following tiny XML document with an embedded signature:
<Payment xmlns="http://payme.not">
<payee>pelle@neubia.com</payee>
<amount>1000</amount>
</Payment>Now look at this:
<Payment xmlns="http://payme.not">
<payee>pelle@neubia.com</payee>
<amount>1000</amount>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" />
<Reference URI="http://www.w3.org/TR/xml-stylesheet">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>60NvZvtdTB+7UnlLp/H24p7h4bs=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
LaL1/t/XodYvDJDgSEbq47GX8ltnlx3FFURdi7o+UFVi+zLf0WyWaQ==
</SignatureValue>
<KeyInfo>
cut for space constraints
</KeyInfo>
</Signature>
</Payment>This looks the same and is perfectly valid. The only thing is that the signature here is not a signature of the payment, where it is embedded. Look closely at the URI attribute in the Reference tag. It is a signature of the XSL specification.
Both of these would validate, because both are valid XML Signatures. If the developer for the bank who is implementing this is not a hardcore xml signature expert he would assume that just verifying the signature would suffice and he would transfer me the $1000.
XMLSignature APIs flawed handling of verification
So lets accept for the moment what some people say about the XML Signature library. It is just a very flexible construction kit for creating Signed Messages. Then the responsibility falls on the apis that people use to write code.
For this you might use a prepackaged ws-security or saml library. I’m sure Verified by Visa and SWIFT all have their own application specific code written by people who are very familiar with the spec.
However what about the generalized XML Signature API’s such as JSR105 or the Microsoft’s System.Security.Cryptography.Xml assembly which is a standard part of .NET. Do they provide an easy way to verify what you are signing? Do they even tell you in their documentation that this is important? Would you know how to do that from reading the Java docs?
JCP105
Most people assume when they call a method such as validate() as found in JCP 105’s XMLSignature class, that it returns true if the signature was valid. To quote the Javadoc for this method:
Validates the signature according to the core validation processing rules. This method validates the signature using the existing state, it does not unmarshal and reinitialize the contents of the XMLSignature using the location information specified in the context.
The example given is long and tedious, but this is the important part:
// Create a DOM XMLSignatureFactory that will be used to unmarshal the
// document containing the XMLSignature
String providerName = System.getProperty
("jsr105Provider", "org.jcp.xml.dsig.internal.dom.XMLDSigRI");
XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM",
(Provider) Class.forName(providerName).newInstance());
// Create a DOMValidateContext and specify a KeyValue KeySelector
// and document context
DOMValidateContext valContext = new DOMValidateContext
(new KeyValueKeySelector(), nl.item(0));
// unmarshal the XMLSignature
XMLSignature signature = fac.unmarshalXMLSignature(valContext);
// Validate the XMLSignature (generated above)
boolean coreValidity = signature.validate(valContext); So if coreValidity is true the signature is valid.
Most are no better
Just to be fair the same examples can be found in most other libraries see:
Apache
This was extracted from the file VerifySignature.java in samples:
// I deleted much irrelevant stuff here
XMLSignature signature = new XMLSignature(sigElement,f.toURL().toString());
signature.addResourceResolver(new OfflineResolver());
KeyInfo ki = signature.getKeyInfo();
PublicKey pk = signature.getKeyInfo().getPublicKey();
boolean valid=signature.checkSignatureValue(pk);This is the explanatory text in the Javadocs(java.security.Key)
Verifies if the signature is valid by redigesting all References, comparing those against the stored DigestValues and then checking to see if the Signatures match on the SignedInfo.
.NET example code and docs
// Create a new XML document.
XmlDocument xmlDocument = new XmlDocument();
// Load the passedXML file into the document.
xmlDocument.Load(XmlSigFileName);
// Create a new SignedXml object and pass it
// the XML document class.
SignedXml signedXml = new SignedXml();
// Find the "Signature" node and create a new
// XmlNodeList object.
XmlNodeList nodeList = xmlDocument.GetElementsByTagName("Signature");
// Load the signature node.
signedXml.LoadXml((XmlElement)nodeList[0]);
// Check the signature and return the result.
return signedXml.CheckSignature(Key);You know this is absolutely correct accoding to the standard. It just however highlights the flaw. When you sign something by pen you have a pretty good visual cue to what you are signing. The same when you validate a signature.
The importance of simplicity and understandability in Security standards
Standards for security and signatures are not the same as css or xhtml where you want maximum flexibility. Signed messages and documents are legal documents and must be written in a clear way so that the people working with them can not misunderstand them. We all know this in the real world.
Lets say you receive a check from some one. Would you accept a check without a signature and a seperate piece of paper that has the signature with the following message?
I Pelle Brændgaard hereby verify that I want you to accept the attached check number #00002344 as being signed by me, even though it contains no signature.
or how about a check which is properly filled out but a little note written in the margin saying this signature applies to the attached document and not to the check.
A court will in most cases rule on the side of safety. If you sign something you didn’t know you signed you would in most cases be able to get the court to squash it.
However this is what the XMLSignature standard wants you to do. In almost all the XMLSignature API’s and implementations when you verify a signature you aren’t actually told what the signature actually signed without digging into the lesser documented parts of the code.
How should it be implemented?
As a matter of a fact the only API (not counting my own NeuClear XMLSig) that does offer examples of verifying what you are saving is Alksey Sanin’s wonderful C based XMLSec library
I know that I shouldn’t be pushing my own library. In particularly as I haven’t the time to maintain it (if anyone is interested let me know). However the following are a couple of examples showing safe verification:
try {
EnvelopedSignature verified=new EnvelopedSignature(elem);
org.dom4j.Element payment = verified.getPrimaryReferenceElement();
} catch (InvalidSignatureException e) {
System.err.println("Invalid Signature");
}This would verify the first of the examples the above, but not the second. You wouldn’t even get a valid reference to a EnvelopedSignature unless it verifies. Therefore you could safely extract information from payment.
I have a generalized abstract class, but no generalized implementation classes. There are Implementation classes for most standardized usages, but it is easy to implement your own if need be.
Crypto should be easy
Crypto tool vendors and standars committees have been pushing all sorts of super complex apis, standards and usage patterns for years. This means that most people give up on using crypto and/or digital signatures in their applications. Many times they are even used badly causing major security issues.
The responsability for this is on the tool vendors. It doesn’t have to be like this.
For an example of how elegant and simple you can do crypto have a look at CryptLib. See also the authors own rant against XML Signatures .
The Java JCE API’s are a mess. However most other apis such as OpenSSL are the same. They where written by crypto geeks for other crypto geeks. They are loaded with jargon such as Cipher, KeySpecs etc. What you need are much simpler higher level frameworks that anyone can use safely without a steep learning curve. I’ve tried to do this in NeuClear Commons with the Signers package. This provides a very simple framework for doing super simple digital signatures.
final PublicKey pub = signer.generateKey("eve");
final byte[] sig = signer.sign("eve", "this is a test".getBytes());As I am mainly doing ruby now a days. I am slowly writing my new EzCrypto library which is designed for anyone to write simple Crypto in ruby. I actually wrote it for StakeItOut my latest project, where almost everything is encrypted on disk.
The following encrypts and decrypts something.
key=EzCrypto::Key.with_password "super secret password", "secret salt"
encrypted=key.encrypt "My secret message"
assert_equal "My secret message",key.decrypt(encrypted)I’ve attempted to create good sensible defaults for everything. The default algorithm is AES128, which you can specify. However most people wont ever need to change this. I haven’t done anything with Digital Signatures yet, but will be implementing that for version 1.1 in the same straightforward manner.
I have always been interested in security and cryptography and have always been annoyed with the security disclosures or lack of them that most web applications offer.
Therefore I am making StakeItOut’s Security Page
painfully public for the world to see. I think it is better for small fish like me to be honest and not end up in a situation with some huge liability on our head.
BTW. I am writing these kinds of things bit by bit in Backpack as I am putting most of my focus on site functionality at the moment. Backpackit is just great for these kinds of things. The next wave of beta testers should be invited in, within the next day or two.