0

I'm looking for a way of transforming an xml document in a way that achieves the following goals:

  • It can be distributed to known applications across the internet and managed by them without any special storage requirements
  • The applications can determine the source of the document
  • The applications can determine if it has been tampered with or altered since it was generated
  • The document is encrypted, but for obfuscation purposes rather than because it contains sensitive information
  • The application can programmatically read the contents of the xml

This sounds like a classic digital signature scenario. However, I do not want the source and recipient applications to have to deal with the logistical issues associated with managing public and private keys.

So, my question is: is there any way of meeting these requirements reliably without the use of digital certificates?

Paul Taylor
  • 5,651
  • 5
  • 44
  • 68
  • 3
    You can't get real security without confronting key management. You have to exchange some key material, whether it's a pre-shared key for some symmetric algorithm, or the public key of a certifying authority in a PKI system. – erickson Apr 30 '13 at 21:00

3 Answers3

3

If you do not really look for security - especially in the forging/alteration aspects, a secret symmetric key embedded in the application would be enough to satisfy alteration detection and encryption aspects. Just use a standard block cipher, and MAC (Message Authentication Code (wikipedia)). Of course, it would be relatively simple to extract the key and alter these documents.

Unfortunately, identifying the source is a little trickier. Identity comes implicitly when you use PKI, because each private key implicitly identifies an entity. Since you do not have such a natural identifier, you will now need to define your own identification scheme: perhaps a MAC address of the first network adapter you see on the machine that runs it, or perhaps a more elaborate scheme where you explicitly assign identities to individual applications, or the individuals that use the application. Once you have some sort of identity definition, it would be a simple matter to add this identification string at the start of your document before encrypt/sign operation as a separate XML field.

vhallac
  • 13,301
  • 3
  • 25
  • 36
  • Thanks for some useful pointers, @vhallac, just what I needed. On reflection, identifying the source of the message is less important in my scenario. The most important factor is to be able to detect whether the original document has been altered. – Paul Taylor May 01 '13 at 08:49
  • So as I understand it, both the source and recipient applications would share a secret key to encrypt/decrypt the document. For a malicious user to tamper with the document without rendering it meaningless, they would need to obtain the secret key, decrypt the doc, alter it and re-encrypt it with the same key. That would be the main vulnerability of this approach? – Paul Taylor May 01 '13 at 08:51
  • 2
    @PaulTaylor Another problem is that if the symmetric key leaks from some application, you will have to replace / update *all* applications in which you have hard-coded the key. With PKI this is different - in case of signing you need to verify validity of the certificate which is pretty much automated procedure and if the certificate is replaced on the signing side, you don't need to replace all verifiers. – Eugene Mayevski 'Callback May 01 '13 at 13:27
  • 1
    @PaulTaylor You are correct. You can try variations of the same approach, but in the end, the actual security of the system will boil down to a secret buried in the application unless you get the users of the application to provide part of the secret in the shape of a password. Making it work for multiple users with different passwords is probably not feasible, though. You would probably be better off using PKI. – vhallac May 01 '13 at 16:26
  • @EugeneMayevski'EldoSCorp You make a very good point. I should have mentioned it in my answer. – vhallac May 01 '13 at 16:28
1

For authentication you need to have some key scheme that ensures this authentication. If you don't like certificates in particular, the alternative is to use OpenPGP keys for XML (XMLDSig supports OpenPGP keys).

Eugene Mayevski 'Callback
  • 45,135
  • 8
  • 71
  • 121
1

[Disclosure: I work for CoSign by ARX]

However, I do not want the source and recipient applications to have to deal with the logistical issues associated with managing public and private keys.

Another way to herd the cats is use PKI but minimize the usual PKI logistical issues by using a centralized SSCD (Secure Signature Creation Device).

Couple it with the ability to automatically generate certs that are already in the trust chain of the recipient's machines. CoSign and others do this.

The resulting digitally signed XML files can be easily verified for identity/authenticity and integrity by the recipients while minimizing the administrative burdens of signing the XML files.

Larry K
  • 47,808
  • 15
  • 87
  • 140
  • That's helpful too, thanks @Larry K, I'll look into it. However, even that may not be feasible in the scenario I am considering, as it would require sufficient privileges to access a server certificate store. – Paul Taylor May 02 '13 at 12:39
  • Re: sufficient privileges to access a server certificate store -- On the signing machine or on the recipient/verification machines? – Larry K May 03 '13 at 08:14
  • Both, but recipient particularly. – Paul Taylor May 03 '13 at 08:26