0

I'm going to implement digital signatures for corporate use. For that, I would develop an application for signatures, generate public/private keys for all employees and store private keys in the Active Directory database.

To sign the document in the application, an employee has to authenticate via LDAP, using his login/password. The application would get his private key from Active Directory, hash the document and encrypt it with the private key.

The generated cipher would be stored in the database. Users may download the signature list for a given document, and check the signatures if required (as public keys are known).

What are the cons of this method?

schroeder
  • 125,553
  • 55
  • 289
  • 326
Leeloo
  • 113
  • 3
  • 1
    Why are you rolling your own? And what is the use case? Is this internal only? What kind of documents are you trying to sign? Word and Acrobat both support certificate based signing where the signature is stored in the document. This way you could get a certificate from a CA and distribute the documents without external bodies needing to install your custom software. – Hector Nov 10 '17 at 10:51
  • It's internal only – Leeloo Nov 10 '17 at 10:52
  • Then you can do the above but create your own internal CA to avoid having to pay for a certificate. The root certificate can be distributed via Group Policy. – Hector Nov 10 '17 at 10:54
  • I would generate keys and store in ActiveDirectory – Leeloo Nov 10 '17 at 11:02
  • 1
    As I asked - why are you rolling your own? And what is the use case - i.e. why are you doing this? – Hector Nov 10 '17 at 11:07
  • It's for internal usage. To sign the internal docs. What do youo mean by `create your own internal CA`? Could you please share some links? And how the docs would be signed in this case? – Leeloo Nov 10 '17 at 11:08
  • 1
    @Leeloo - I mean you should use standard certificate generation tools and signing tools. At the very least this means your organisation should create a root certificate authority (CA) that signs users public keys. Then beyond this if the document formats you wish to use support it (office and pdf do) then you should use the certificates with the built in signing mechanisms to sign the documents. – Hector Nov 10 '17 at 11:31
  • 1
    I think the biggest problem here is that you have a centralized database of the private keys. The raison d'être of using public key infrastructure is decentralization of security. If you're going to spend the time and effort to make a secure central LDAP database for this to work, you might as well spend that time and effort on securing the signing application and then you would not have to have the complexity of PKI. Just store who had signed what in the database, rather than storing cryptographic signatures, is much simpler to implement. – Lie Ryan Nov 10 '17 at 12:55
  • I'm in agreement with the others. There is no need to develop your own application. Windows tools exist to do all this for you. The cons are that you are not experienced enough to accomplish this successfully (few people are). – schroeder Nov 10 '17 at 14:14
  • Thanks, I aggree with you, but the reason of development of my own CA is that, I want to integrate it with my website, so to be able to sign docs in the webpage – Leeloo Nov 10 '17 at 14:36
  • @Leeloo Microsoft tools can integrate with web servers, too – schroeder Nov 10 '17 at 16:14
  • @schroeder could you please share some links? – Leeloo Nov 10 '17 at 19:13

1 Answers1

1

You seem to want to roll your own signature infrastructure. As @Chenmunka points out this is almost always a bad idea.

A few questions remain outstanding.

  • You want to store the private keys in LDAP but the signatures in a database. Why not just store the keys in the database? If a user gains more access than they should to the database they can just replace the signatures - so having the keys there is no less secure.
  • How are public keys distributed and verified?
  • How do you enforce your users actually sign documents and check signatures?

Without establishing your full use I can't know for certain but it feels like there is also no need for this system. What does it establish? It feels like it will be clunky and a pain for users to use - which means they will find ways around it.

If you just want to be able to prove who edited a document there are built in tools in Windows. See audit object access.

Alternatively if you want users to be able to easily check who authored a document there is support for this built into many common document formats. These bake the certificates into the documents and allow verification via certificate chains inside of the editor - i.e. you only need to add the root certificate to users machines which can be done via group policy. All office formats and PDF support certificate based publisher signing. You could create your own root certificate authority and issue each user a key (or ideally have them generate certificate signing requests - that way the organisation does not have to hold the users private key and administrators cannot easily forge signatures).

Hector
  • 10,923
  • 3
  • 41
  • 44
  • Thanks, I aggree with you, but the reason of development of my own CA is that, I want to integrate it with my website, so to be able to sign docs in the webpage – Leeloo Nov 10 '17 at 14:35
  • 1
    Why? This sounds like a pain for users when their editors can do it anyway. What advantage do they get from using a website? Even if you want to do this you shouldn't be storing users keys in LDAP. And you can still proramatically sign documents within their format. I.e. for office documents look at openxml - https://blogs.msdn.microsoft.com/mszcool/2007/07/31/digitally-signing-office-open-xml-packages/. – Hector Nov 10 '17 at 14:52
  • It's easier to store in LDAP, because user has to write his credentials only to sign the document. He doesn't have to install certificates in the browser or use a smart card – Leeloo Nov 10 '17 at 19:16
  • Why not just have them keep the keys in their roaming profile? That way they can stay installed in the normal document editing applications? – Hector Nov 11 '17 at 20:09
  • @Leeloo and as I said before if you insist on rolling your own why not just store them in the database with the signatures? If you can access the database in ways you're not supposed to you can just replace the signatures... – Hector Nov 11 '17 at 20:11
  • I don't want them to download the document for signing. I need it to be signed in my web application. On the other hand, I don't want to store the private keys in the DB of web application. That's why the LDAP looks like an optimal choice – Leeloo Nov 11 '17 at 20:12
  • Also, different people have access to LDAP DB and web application DB. That's the security in my case – Leeloo Nov 11 '17 at 20:13
  • Replacement of the signatures may be done only be me hypotetically. No one else has access to both LDAP and web DB – Leeloo Nov 11 '17 at 20:15
  • Why sign at all then? Just have them authenticate with the Webapp via LDAP and store in a database record that they have accepted that version. If the webapp is trusted to sign the documents then it has access to the private keys - meaning if it is breached you can't trust any signatures. So they achieve nothing more than a db record saying user X accepted it. – Hector Nov 11 '17 at 21:11
  • A record 'someone signed' stored in DB may be easily replaced. Signature-no. The webapp doesn't store the keys, it just gets required one on the basis of user creeentials – Leeloo Nov 12 '17 at 08:54
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/68613/discussion-between-hector-and-leeloo). – Hector Nov 12 '17 at 14:41