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?

Improve this question
12
  • 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, 2017 at 10:51
  • It's internal only
    – Leeloo
    Nov 10, 2017 at 10:52
  • 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, 2017 at 11:07
  • 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, 2017 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, 2017 at 12:55

1 Answer 1

Reset to default
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).

Improve this answer
11
  • 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, 2017 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 - blogs.msdn.microsoft.com/mszcool/2007/07/31/….
    – Hector
    Nov 10, 2017 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, 2017 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, 2017 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, 2017 at 20:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .