Digital Signature Service

[kohsah]

Currently we have https://github.com/gawati/gawati-package-sign which is a java library that digitally signs XML documents. It needs to be converted into a service that accepts a gawati-editor-ui, package and required signature inputs -- applies the signature and sends back the signed document.

Note that the editor document package is composed of both XML metadata and an attachment. The attachment is currently not signed in the current implementation, and that needs to be implemented. The attachments can be in different formats. the signature implementation for the metadata is XML aware so it is a distinct use case from the attachment. We can treat the attachments as string streams and sign it in those terms -- i.e. it would not embed the signature in the attachment, but would be more like e.g. generate the checksum of the attachment file and sign the checksum - so if someone changes the attachment, we can always validate it with the signed checksum. The signature on the checksum itself ensures the checksum is not tampered.

[ccsmart]

Currently we have https://github.com/gawati/gawati-package-sign which is a java library that digitally signs XML documents. It needs to be converted into a service that accepts a gawati-editor-ui, package and required signature inputs -- applies the signature and sends back the signed document.

My current understanding is that this is meant to describe a signing service on a central / public server which shall get a copy of personal key for signing content on behalf. We can't do that. It would be more close to conspiracy than security and we'd be better off not doing signatures to begin with in such case. The whole idea is about verifying and securing not letting in falsification and getting your name attached to such. The potential of getting your name attached to signing falsified data on behalf and in name of is even less attractive.

[ccsmart]

but would be more like e.g. generate the checksum of the attachment file and sign the checksum - so if someone changes the attachment, we can always validate it with the signed checksum. The signature on the checksum itself ensures the checksum is not tampered.

The checksum could be a metadata entry alongside the attachment file reference in the XML.

[kohsah]

@ccsmart

1) No .. no there is no central / public server here. There is a signature service that runs within the controlled environment of the editor (not online on the public internet). It is intended for use only within the editor scenario. The client - > server interaction is there only in that context since the editor-ui is pure frontend sandboxed there is no real way to sign documents pure-frontend (which we had discussed sometime back) without applets or activex controls. You are signing it as an authenticated user who has a private key. I hope that is clear ?

2) Yeah thats how the checksum will be stored.

[ccsmart]

I see no difference between the public nature of the portal and the public nature of the editor with regards to security in both cases of ALL and a hosted instance. It is not a question whether in the context of Gawati system this is considered more inside or more outside. It is about attack surface and in this regard, editor is expectably worse than portal due to higher complexity and number of components.

"there is no real way to sign documents pure-frontend" i do not agree without adding under which conditions that are considered mandatory for this. Those conditions i will then argue are less mandatory than security when it comes to identity theft in signing legal documents. So i would prefer we discuss which way we choose to implement a non browser, dedicated software component on the client, which is really what we discussed intially.

[kohsah]

@ccsmart Sure discussion is always fine. Note that the signing aspect is NOT a browser component. For a pure browser based solution you need a complete implementation of web crypto apis in the browser. The existing implementations are incomplete / crippled in most browser implementations - we cannot build something on experimental technology. e.g. there is no web crypto key discovery api implementation in chrome - which is the first step to digitally signing anything. What exists are a bunch of hacks, or commercial plugins or java applets or dongle based solutions -- none of which form a sustainable solution.

I dont see how having the signature as a service separate from the browser increases the attack surface if its deployed in the recommended manner.

[kohsah]

@ccsmart most modern digital signature solutions are by the way service based - e.g.docusgin, globalsign, OASIS even has a standard for it called DSS. Along with that our system's architecture is completely REST/ Service based .

[ccsmart]

It is understood that browser based solutions have had issues with compatibility. At the time, looking at the options led to the option of client side application.

I dont see how having the signature as a service separate from the browser increases the attack surface if its deployed in the recommended manner.

Then please clarify again where exactly this is meant to execute, where the document to be signed travels from/to and where the private key is meant to be accessed / transferred? / signature to be computed.

Regarding docusign etc. whichever way they might do it, the least we can say is that we have less time, less focus and less capability on security compared to either of these.

[kohsah]

@ccsmart Ok lets start with the service, the signing service itself is a typical service that runs on a host:port. it accepts a document and a signature as input and returns back a signed document. there is a separate validator service that validates the signed document. How secure you want is really a factor of how you deploy it. The editor is a front-end app with back-end components deployed within your local area network. You have multiple options of how you want to deploy this digital signatue service:

1. lets say you have a network of 3 users and only one of those users is an allowed signatory, the most secure way to set-it up is to deploy the signature service only on the signatory's computer listening only on localhost - that way any signing can be locked down to a specific workstation. Any document / key transmission happens only between the browser and the locally deployed service.

2. if you believe your network is secure and all 3 users are signatories, you deploy the service on your network giving access to all 3 users (or install it locally on their 3 workstations)

3. you could go a step further and bake in the key into the local installation so a submission by the authenticated user form the editor front-end is signed by the local service and returned (there is no key transmission even over the loopback/localhost adaptor required in this case)

My point with the above - there are multiple deployment scenarios possible, the service by itself is not insecure, its how you deploy it. if you deploy it as a client side application then its very secure, network side application less secure, deployed on the internet even less secure :-)

In terms of the encryption and signing itself we aren't inventing something ourselves, we are using crypto apis provided by the java platform, it is more of a deployment function of how secure / insecure it is. e.g. where are the keys being stored ? are they deploying with valid ssl certs ?

Technically docusign may seem secure, but its very difficult to have a completely secure system when its browser based, you need a completely closed loop. e.g. docusign have been the subject of various kinds of attacks most commonly phishing attacks where subscribers got phishing emails as if it was from docusign, which people submitted sensitive information to. So their most common attack vector wasnt entirely a technical one (their customer email addresses got compromised), but more of a social one.

[ccsmart]

runs on a host:port. it accepts a document and a signature as input

Seems like a typo... "signature" meant to say "private key", correct ?

The editor is a front-end app with back-end components deployed within your local area network.

It may be deployed internally. Whatever the statistics will be, the original one, for ALL, is not. It's a community system.

lets say you have a network of 3 users and only one of those users is an allowed signatory, the most secure way to set-it up is to deploy the signature service only on the signatory's computer listening only on localhost

This would be an installation, or an execution based on a fetch from the web, ie editor-ui site?

the service by itself is not insecure

By default, nothing is secure, but we cant fix everything for others. What we have to take care of is not to circumvent, make it harder to maintain, copy sensitive data or subject them to excessive risk based on what is in place. Copying a private key for signing legal documents off an official entities infrastructure onto a public one does violate on each of those duties.

deployed on the internet even less secure :-)

An understatement for the very issue. ALL, per above description, would be that case if i'm not mistaken. However, if said service can be installed on the enduser system to sign the document for and while using an internet deployed portal editor without another internal service deployed in a low tech office, then thats fine. That would be a locally installed signing without transfer of the private key. Ideally that should have its own password dialog for decrypting the encoded key.

In terms of the encryption and signing itself we aren't inventing something ourselves, we are using crypto apis provided by the java platform, it is more of a deployment function of how secure / insecure it is. e.g. where are the keys being stored ? are they deploying with valid ssl certs ?

Thats a very valid point. Things usually go wrong "in between". For example, assuming "document" in the input is the akn xml, how does the signature service ensure that the contained hashes for the underlying files are truly those representing the files the user expects to be signing? The question assumes that the checksum will have been generated by portal editor in this case. If thats incorrect, the question invalidates as is, but its more meant to remind that we have to be careful.

Technically docusign may seem secure, but its very difficult to have a completely secure system...

I'd prefer to leave all this local to the user to begin with. Just referencing in this regard.

[kohsah]

@ccsmart yeah sorry meant private key there rather than signature

This would be an installation, or an execution based on a fetch from the web, ie editor-ui site?

Its a deployment question here - you could even run editor-ui on localhost or on a network server, but for signing its going to refer to the localhost service, so the signing will work only from the host which has the signing service installed, and the user must know the signing password.

Yes, the most secure scenario where the signing service is delivered with the key as a packaged unit ... no transmission of key required its entirely local and encapsulated within the service.

Sure nothing is entirely secure, if the local desktop is compromised all bets are off anyway.

[ccsmart]

So is it that you can install the intended signing service locally (assuming its effectively one reasonably small installation), on users machine, without installing full editor (bunch of requirements) and sign a document on remote, public web hosted editor ?

Or would you need a full editor installation ?

[kohsah]

@ccsmart so you would have the editor-ui hosted (just like portal-ui) within the network (or online) and just the signature service installed on the one computer. That way the only overhead for repeated installation is the digital signature service installed on a specific computer (wont be much just a jetty container with a service within it). Transmission of data is still local because its a local ajax call (i.e. assuming other services are hosted remotely) from the client browser to the signature service. Signed document in such a case will get transmitted to the within-network or remotely hosted storage service as the case may be.

[kohsah]

@ccsmart

For example, assuming "document" in the input is the akn xml, how does the signature service ensure that the contained hashes for the underlying files are truly those representing the files the user expects to be signing? The question assumes that the checksum will have been generated by portal editor in this case. If thats incorrect

This is something to think about. So the documents are stored on the server,

1) user initiates signing request, the document is returned from the server along with its checksum. 2) Document is sent for signing with returned checksum, before signing the Document, signing service recalculates the checksum and matches it with what was sent, if it does not match it does not go ahead with the signing.

Would that make sense ? I am not really sure... if you assume the files can be tampered in transit then even the checksum can be tampered in transit when the file is returned (in (1) ). But if the transport is over ssl is this even a significant problem ?

[kohsah]

@ccsmart One question is regarding the public key. If a document is signed the assumption is the public key for the document is accessible on the portal - since we need to be able to validate signatures on the portal if a user clicks a "validate" button for instance on the portal ? What do you think ?

[ccsmart]

1. user initiates signing request, the document is returned from the server along with its checksum.

This one is tough, as there will be large documents of many pages which you cannot expect the user to be able to verify for correctness.

2. Document is sent for signing with returned checksum, before signing the Document, signing service recalculates the checksum and matches it with what was sent, if it does not match it does not go ahead with the signing.

The problem case is the expectation of intereference to make the user sign sth modified. Rehashing locally of the remote document IMO doe snot resolve the primary issue.

It seems to me it will be necessary to create the checksum of a local known correct version.

In transit i'm not as worried about (comparing statistically) relative to a hacked Gawati instance.

[kohsah]

@ccsmart there is no "local" , its a browser based network system. There is editor-ui providing the ui and there is editor-fe providing back-end access running within their network. The document is already in the system - and one of the workflow steps after review is the signing step. So, what is "local" ?

[ccsmart]

assumption is the public key for the document is accessible on the portal - since we need to be able to validate signatures on the portal if a user clicks a "validate" button for instance on the portal ?

the public key can stored anywhere. it would be useful if we can tap into existing key verification systems, as storing a single copy just on our site would allow replacing that with a third party one claiming to be the original. The availability of the copy of a key is not an issue, the trust in it being genuine is.

clicking validate button seems not as useful. Gawati can do an initial check as a condition to display the "signed document" indicator logo.

Proper verification if need be woudl have to be done locally by client again, fetching public key, ideally from a distributed trust system. If there is independent software for verifying signatures available... would be ideal if we can use such.

[ccsmart]

there is no "local"

there is.

case 1 ) it is either the same user that uploaded the original, or a user of the same organisation with access to the original copy which is reused for the signature creation.

case 2) it is a user who downloaded a copy off the server, that copy he verified and reuses it for signing.

[kohsah]

@ccsmart I don't understand how case (1) or (2) are supposed to work. there is a workflow:

1) A user introduces a document into the system for input and adds basic metadata. 2) Another user adds additional metadata. 3) Another user reviews and approves it for publication at which point it is available for signing. 4) An Authorized user signs the reviewed document and it gets published.

This is a workflow i have see across organizations. At point (4) the document has already gone through a chain of escalating approvals and is authorized. Do you really think in a practical scenario user at (4) is going to re-upload and re-sign what has already been reviewed by others ? There is no "local" metadata anyway and the attachment is already in the system. Unless the user is explicitly worried that his local system is compromised 99% of the time they are going to sign.

[kohsah]

@ccsmart

clicking validate button seems not as useful. Gawati can do an initial check as a condition to display the "signed document" indicator logo.

So we can do an initial check as a background process and capture the time when the signature was verified., and show the document as "digitally verfied on YY-MM-DD at HH:MM ...

[ccsmart]

4. An Authorized user signs the reviewed document and it gets published.

This is a workflow i have see across organizations. At point (4) the document has already gone through a chain of escalating approvals and is authorized. Do you really think in a practical scenario user at (4) is going to re-upload and re-sign what has already been reviewed by others ? There is no "local" metadata anyway and the attachment is already in the system. Unless the user is explicitly worried that his local system is compromised 99% of the time they are going to sign.

The workflow is correct. But i'm considering the upload more of an operation of making static data available to the server for distribution than as an upload to a data manipulation system / editro wrt to the document as such. Editor is the metadata editor. IE i', not looking at it as signing "that" copy, i'm looking at it as signing "our" copy - the original. "That" copy is outside of control.

In step 4 the actual document may, or may not be on the server. In any case there is no re-upload, no initial upload and no re-sign. IMO in step 4 the signing client received the latest copy of the metadata (imo, no need for a hash in ther) and displays it. Signing user indicates the local document that matches that metadata and hash is locally created. Then that is signed and the metadata with signature uploaded.

Either that metadata then finds the matching file already to be in place, or somebody can upload it later.

IMO one may even choose to not upload the file ever, still allowing a metadata contained remote document to be available at designated location and with the possibility to verify with the embedded signature.

[ccsmart]

show the document as "digitally verfied on YY-MM-DD at HH:MM ...

i'd prefer to just indicate that its signed. IMO true signature verification we cannot do as a service and we shouldnt indicate such.

[kohsah]

@ccsmart

The workflow is correct. But i'm considering the upload more of an operation of making static data available to the server for distribution than as an upload to a data manipulation system / editro wrt to the document as such. Editor is the metadata editor. IE i', not looking at it as signing "that" copy, i'm looking at it as signing "our" copy - the original. "That" copy is outside of control.

There is a fundamental misunderstanding here. The document that the user is adding to the system is an "attachment" to the metadata XML envelope. We sign the metadata XML envelope which includes the checksum of the attachment. This is a true digital signature in the technical sense since it is embedded in the XML. If you tamper with the metadata XML the signature is invalidated.

For the attachment we do not embed a signature into it, since the format or nature of the document is not predictable - since, every format has its own distinct way of signing it natively, and then there could be other constraints e.g. the document is encrypted, read-only or protected in some other proprietary way. All we are promising is that we have a way to check what you input into the system is what is being presented on the portal that is what the checksum + signing of the metadata xml achieves. Fundamentally we cannot sign the copy out of our control.

IMO one may even choose to not upload the file ever, still allowing a metadata contained remote document to be available at designated location and with the possibility to verify with the embedded signature.

The metadata without a corresponding document would have no meaning. It would be like an OAI citation nothing more.

[kohsah]

@ccsmart

i'd prefer to just indicate that its signed. IMO true signature verification we cannot do as a service and we shouldnt indicate such

What we could do is provide a web-based service for signed documents, where someone can upload a document and verify its validity against what is in our database. That could be easily achieved.

[ccsmart]

What we could do is provide a web-based service for signed documents, where someone can upload a document and verify its validity against what is in our database. That could be easily achieved.

I dont see the picture clearly as of yet...

Signing we do on the metadata (only). So we have signed hashes for files. Uploading i think might not be needed in that case.

Can it be a piece of code that runs locally, allows to open a file, calculates its hash and compares to hashes fetched from Gawati metadata ? Ideally this client would fetch and verify a public key with web of trust and confirm the validity of the signature covering the Gawati hash... ?

[ccsmart]

"attachment" to the metadata XML envelope.

Am not sure understanding the wording. My take is we have Akoma Ntoso XML metadata that -references- the file for its storage location (public URL) and the hash of its content.

The metadata without a corresponding document would have no meaning. It would be like an OAI citation nothing more.

Sort of. Nonentheless IIRC we wanted to offer the option to reference remote documents which IMO was inherently possible through the approach with Akoma Ntoso.

[ccsmart]

actually, link to the file might better be outside the signed data. Just the "primary" metadata regarding the file and its hash.

[ccsmart]

reagrding keys, verification and distribution:

https://www.gnupg.org/gph/en/manual/x457.html

verification example:

https://riseup.net/en/canary

[kohsah]

Signing we do on the metadata (only). So we have signed hashes for files. Uploading i think might not be needed in that case.

we sign the metadata sure, but we also have the hashes of the attachments which are part of the signed metadata document. So if we read the hashes from the signed metadata ... and compare it to the hash of the provided that should catch the most obvious duplicates.

Can it be a piece of code that runs locally, allows to open a file, calculates its hash and compares to hashes fetched from Gawati metadata ? Ideally this client would fetch and verify a public key with web of trust and confirm the validity of the signature covering the Gawati hash... ?

Can be the validator is a service can also be accessible from the command line .. but in terms of practical usage much easier and simpler as a web based service.

[kohsah]

Am not sure understanding the wording. My take is we have Akoma Ntoso XML metadata that -references- the file for its storage location (public URL) and the hash of its content.

The metadata XML file is just a manifest to the attachment. it describes what is the attachment. The metadata file by itself has no meaning because its metadata without content. We have to think of them as one unit.

Sort of. Nonentheless IIRC we wanted to offer the option to reference remote documents which IMO was inherently possible through the approach with Akoma Ntoso.

There is no local / remote specification in akomaNtoso ... there are just IRI references, how those references are resolved is not prescribed, but just covered by general recommendations. So you can have a document referring to other documents (and those references could be remote ... depends on the resolver) . In this case, of the document and attachment there are all local to each other , the attachment is not a different document, the metadata xml is just a manifest / encapsulator on that. THink of it like a database record with a blob / binary field.

[ccsmart]

The metadata XML file is just a manifest to the attachment. it describes what is the attachment. The metadata file by itself has no meaning because its metadata without content. We have to think of them as one unit.

Metadata is data on its own. Knowledge that something does exist, even if you dont have the content (yet) makes you look for the right thing.

For the signing and structuring i'd like to be clearer on how the data is distributed "physically".

the metadata xml is just a manifest / encapsulator on that. THink of it like a database record with a blob / binary field.

Still not fully clear barebones statement imo.

Do we have Metadata in Akoma Ntoso together with actual document in one file ? Ie a mime / base / text encoded block within an XML attachment block ? Or is it 1 Akoma Ntoso / XML file for metadata and the original file in binary form as a separate object.

The former i think would not be ideal, the latter necessary. For both, managing size (revisions with each metadata change / managing database content, distributing data) and signing.

[kohsah]

Or is it 1 Akoma Ntoso / XML file for metadata and the original file in binary form as a separate object.

This is how we store it ... the metadata XML is stored along with the corresponding data file. When its sent for signing to the service, it is sent together as one unit. The hash for the data file is calculated by the service and injected into the metadata XML, and then the metadata XML is signed using crypto APIs which in turn introduce the signature into the XML file.

Here is the API outline: https://github.com/gawati/gawati-package-sign/blob/dev/README.md

[ccsmart]

This is how we store it... the metadata XML is stored along with the corresponding data file.

Good

When its sent for signing to the service, it is sent together as one unit.

1) From a central, in case of ALL public service. So said service would have to guarantee it has no been tampered with -before- signing it. One part of signing has the purpose of avoiding for ALL to have the repsonsibility and the provider genuinely being able to make a certification statement, so cat is chasing its tail this way.

2) User cannot do a qualified review upon signature for the document from in this case external source.

With this scheme, signing would only be available user who choose a full, in-house installation of Gawati Editor under own, non hosted regime.

the metadata XML is signed

I understand that is with the "binary" document stripped. Which imo be right.

To at least allow for both i would prefer the availability of the option to choose a local file as source for hash and signing. IMO a requirement for smaller scale users.