To: Rathie, Ian (FUSA) Subject: Info re XML security XML and how to secure it Mon, 22 May 2000 10:17:29 GMT Kevin Townsend The eXtensible Markup Language's enormous potential as an enabling technology for e-commerce will only be realised when its inherent security weaknesses are eliminated · The eXtensible Markup Language (XML) is widely seen as the successor to HTML. It is considered so important that it has been described as the new · Ascii of the Internet, allowing interaction between different hosts regardless of operating system. But what is it, and why is it so · important? XML derives from Standard Generalised Markup · Language (SGML), an ISO standard, as does the Web's HTML. But XML is easier to use than SGML and can be considered as a far more powerful superset of HTML. In reality, however, it is best to contrast rather · than compare HTML and XML. HTML operates as an access and display mechanism that lets the user · access files, and defines how the information in · the files should be displayed on the screen. It · has a predefined and limited number of display tags with which to do this. XML is not a display mechanism; it is designed to · transport and define data. It is extensible and has a limitless number of tags. This is the main difference between XML and HTML: XML tags are defined by the author and contain and define data; HTML tags are predetermined and contain and define the appearance of data. Limits of HTML HTML appeared when accessing information held on computers in far-away countries was still a novel experience for most people. It was more than enough on its own. But the world has changed, and people want more from the Internet. We now want to · use it for business and banking as well as education. And HTML is no longer enough. Although HTML provides us with forms to transmit data, it is limited and clumsy. XML will change all this. The key will be XML schemas and document type definitions (DTDs). Both do the same thing: they define the tags that define the data used in an XML document. DTDs are the original SGML approach; schemas are a more flexible alternative, such as the BizTalk framework developed by Microsoft. Schemas are likely to be the more widely adopted, partly because they are supported by Microsoft but also because they offer genuine advantages. Also key is the club, or industry grouping. Clubs define and agree standard schemas for specific purposes. One of the first was the Business and Accounting Software Developers' Association (Basda), which has developed its eBIS-XML schema. As long as different firms use the same schema, eBIS-XML enables the direct exchange of purchase orders and invoices between different accounting software packages, via email and the Net. These schemas are available free from the BizTalk Web site, set up by Microsoft as a repository for XML schemas. About 100 developers have already confirmed that they will implement eBIS-XML in their products. "We have taken an entirely new approach to EDI using existing XML technology to create a simple, affordable, easy-to-use, many-to-many interface which works with any business software package," says Dennis Keeling, chief executive of Basda. "EDI has been around for 20 years yet less than one percent of organisations around the world use it because it is so complicated and costly to implement. Basda's 350 members handle the other 99 percent of transmissions by printing out on specialist stationery orders and invoices generated by one computer system, which are then sent by mail and keyed into another system, at great cost in time and materials." The eBIS-XML initiative aims to eliminate the need for costly value-added networks and bring simple electronic exchange of documents within the reach of the smallest business, says Keeling. This is what XML is about -- it is the mortar that will bind the bricks of true e-commerce. It will enable purchasing, payment, banking and a myriad other applications to be performed easily and seamlessly over the Internet. In a few years we will all be buying goods and moving money from one account to another via XML over the Internet. And that is the one big problem. The Internet is as insecure as ever, and XML will do nothing to improve it. In fact, the temptation to intercept and alter an XML document containing vital data en route from one banking application to another will lure many an Internet vandal. There are two primary requirements: encryption to keep confidential information private; and digital signatures to provide authenticity, integrity and non-repudiation. The encryption side is not too difficult. The only important point is that any encryption should be a well-known, tried and tested algorithm that is specifically resistant to known plain-text attacks. The point here is that published schemas will contain data about the tags used in specific XML documents, and the tags themselves can be quite long. These could be used to provide enough known plain text for an attack. The better-known encryption algorithms are fairly resistant to such attacks, and it should not be a problem if recognised standards are followed. Digital signatures But digital signatures are different, and provide a problem that is being worked on jointly by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF). The target is a standard for digital signatures for XML just as S/Mime provides a digital signature standard for email. "Digital signatures provide integrity, signature assurance and non-repudiatability over Web data," explains the W3C/IETF documentation. "Such features are especially important for documents that represent commitments such as contracts, price lists and manifests. In view of recent Web technology developments, the proposed work will address the digital signing of documents using XML syntax. This capability is critical for a variety of electronic commerce applications, including payment tools." It is a joint exercise because it requires expertise in XML ­ from the W3C -- and cryptography ­ from the IETF. Digital signatures require the use of Public Key Infrastructures: public key cryptography plus the means to find and verify the sender's public key. But it is not as simple as it may seem. Digitally signing an email message involves person A creating a hash of the message itself and then encrypting the hash value with their own private key before sending it to person B. B knows A's public key and can decrypt the hash. He knows that only A could have sent it because only A's public key will decrypt it. B then recreates a new hash value from the message and compares it with the value sent by A. If it is the same, it proves that only A could have sent the message and nobody has tampered with it. The message has been digitally signed and can be considered safe. But we cannot necessarily apply the same principles to an XML document. For example, the XML document concerned could be a form. In this case the issuing application may wish to sign parts of the document, but will need to allow the user to legitimately tamper with the document by filling it in. Clearly, if we attempted to sign the whole document, any hash value would be altered by the user's additions. We need therefore to be able to sign just parts of the document, and it this an altogether more complex task. Work on such a standard has reached the working draft stage and leading PKI vendors are now developing XML security products that are based on standards. First off the mark was Baltimore with its X/Secure. The toolkit allows developers to build PKI-based security into XML applications. It provides APIs for digitally signing XML documents, for verifying digitally-signed XML documents and for decrypting encrypted XML documents. It also provides support for manipulating certificates and private keys in industry standard formats. Entrust and IBM have been quick to follow. What do you think? Tell the Mailroom. And read what others have said. Take me to the XML Special