about visible digital signatures - itext

Given an input pdf file with visible digital signatures, I would like to obtain a new pdf file that preserves the visual representation of the signatures as graphical objects but not longer as signatures fields.
I have done that with a tool (see the input and the output files) but I would like to know how to do it with iText.
input: input.pdf
output: output.pdf

Please be aware that signatures done well (using a certificate from a CA that is member of CDS or AATL) can be verified so that you can test for (1) "integrity", (2) "authentication", and (3) "non-repudiation". By throwing away the signature fields, you lose all that information and nobody will be able to know if the document was changed after signing (1), nor who signed the document (2). The signer can always claim that he never signed that document (3) because anyone could have created the visual representation of his signature.
By removing the signature you will create a copy without an actual signature, similar to what you'd have if you printed a document that is digitally signed. You'll be throwing away important information by removing the actual digital signature, keeping only the visual appearance.
This being said, you are asking for something very simple: you want to flatten a PDF file. This is shown in the FlattenSignature example. Check the file output_no_longer_signed.pdf and you'll notice that it looks exactly like your output.pdf.
The code to achieve this is very simple:
public void manipulatePdf(String src, String dest)
throws DocumentException, IOException {
PdfReader reader = new PdfReader(src);
PdfStamper stamper = new PdfStamper(reader, new FileOutputStream(dest));
stamper.setFormFlattening(true);
stamper.close();
}

For me Bruno's answer didn't work.
I needed to call setGenerateAppearances(true) the be able to see the flattened signatures
public void flatPdf(String src, String dest) throws DocumentException, IOException {
PdfReader reader = new PdfReader(src);
PdfStamper stamper = new PdfStamper(reader, new FileOutputStream(dest));
AcroFields fields = stamper.getAcroFields();
fields.setGenerateAppearances(true);
stamper.setFormFlattening(true);
stamper.close();
}
with: iText 5.5.13

Related

Dynamics 365 Plugin parse Note attachment XML without using file

In Dynamics CRM online, I have a record in the annotation entity which has an XML attached.
From a plugin, I need to get the content of that attachment and create an XML element so I can deserialize its content as an object class and apply some logic.
As we are in an online implementation, I cannot do things like create a file and read its content.
So what we have is a document content in the attached file, which is a string with multiple characters, as you can see here (attachment is generated by a Power Automate flow):
Here is some of my code:
byte[] fileContentBytes = Encoding.Default.GetBytes(note.DocumentBody);
MemoryStream stream = new MemoryStream(fileContentBytes);
StreamReader globalReader = new StreamReader(stream);
XmlDocument doc = new XmlDocument();
doc.Load(globalReader);
The error message says that Data at the root level is invalid. Line 1, position 1, as it's trying to parse as an XML something that is not parse-able as that.
Power Automate is generating JSON document, you are trying to parse it as XML, so failing.
Instead try some methods to convert to your needed format.
The document body is base 64 encoded.
Try the following
byte[] fileContentBytes = Convert.FromBase64String(note.DocumentBody);
MemoryStream stream = new MemoryStream(fileContentBytes);
StreamReader globalReader = new StreamReader(stream);
XmlDocument doc = new XmlDocument();
doc.Load(globalReader);

The api server cannot create the file when receives a put request

I am new in APIs. I have a java api server. In put method on server side, i receive a string and i create a arff file using that string. then i do some process on that file and return the result which is another string.
The problem is that when i do a put request the file is not created in local path, but when i run the code on a local application for test the file is created so the code works.
I have to generate a file of that string because i am using a machine learning algorithm that only works with files.Does anyone know why is that?
the method Classify text is called in put method in server side
public static int ClassifyText(String trained_model, String text) throws FileNotFoundException, IOException, Exception {
String evaluation_file = "..\toBeClassified_text.arff";
//create a arff file for the text
FileWriter fileWriter = new FileWriter(new File(evaluation_file));
PrintWriter printWriter = new PrintWriter(fileWriter);
The problem is solved by modifiying thisline:
String evaluation_file = "D:\toBeClassified_text.arff";

How do I sign a PDF with a Smart Card in a web context using iText?

Read through the following references:
iText Digital signature white paper, and C# examples. (specifically chapter 4) For those interested, another great and concise summary of the PDF signing process.
CAPICOM documentation.
Online examples / questions here and on iText mailing list archives, such as here and here.
Hashing code:
BouncyCastle.X509Certificate[] chain = Utils.GetSignerCertChain();
reader = Utils.GetReader();
MemoryStream stream = new MemoryStream();
using (var stamper = PdfStamper.CreateSignature(reader, stream, '\0'))
{
PdfSignatureAppearance sap = stamper.SignatureAppearance;
sap.SetVisibleSignature(
new Rectangle(36, 740, 144, 770),
reader.NumberOfPages,
"SignatureField"
);
sap.Certificate = chain[0];
sap.SignDate = DateTime.Now;
sap.Reason = "testing web context signatures";
PdfSignature pdfSignature = new PdfSignature(
PdfName.ADOBE_PPKLITE, PdfName.ADBE_PKCS7_DETACHED
);
pdfSignature.Date = new PdfDate(sap.SignDate);
pdfSignature.Reason = sap.Reason;
sap.CryptoDictionary = pdfSignature;
Dictionary<PdfName, int> exclusionSizes = new Dictionary<PdfName, int>();
exclusionSizes.Add(PdfName.CONTENTS, SIG_BUFFER * 2 + 2);
sap.PreClose(exclusionSizes);
Stream sapStream = sap.GetRangeStream();
byte[] hash = DigestAlgorithms.Digest(
sapStream,
DigestAlgorithms.SHA256
);
// is this needed?
PdfPKCS7 sgn = new PdfPKCS7(
null, chain, DigestAlgorithms.SHA256, true
);
byte[] preSigned = sgn.getAuthenticatedAttributeBytes(
hash, sap.SignDate, null, null, CryptoStandard.CMS
);
var hashedValue = Convert.ToBase64String(preSigned);
}
Just a simple test - a dummy Pdf document is created on initial page request, hash is calculated, and put in a hidden input field Base64 encoded. (the hashedValue above)
Then use CAPICOM on client-side to POST the form and get user's signed response:
PdfSignatureAppearance sap = (PdfSignatureAppearance)TempData[TEMPDATA_SAP];
PdfPKCS7 sgn = (PdfPKCS7)TempData[TEMPDATA_PKCS7];
stream = (MemoryStream)TempData[TEMPDATA_STREAM];
byte[] hash = (byte[])TempData[TEMPDATA_HASH];
byte[] originalText = (Encoding.Unicode.GetBytes(hashValue));
// Oid algorithm verified on client side
ContentInfo content = new ContentInfo(new Oid("RSA"), originalText);
SignedCms cms = new SignedCms(content, true);
cms.Decode(Convert.FromBase64String(signedValue));
// CheckSignature does not throw exception
cms.CheckSignature(true);
var encodedSignature = cms.Encode();
/* tried this too, but no effect on result
sgn.SetExternalDigest(
Convert.FromBase64String(signedValue),
null,
"RSA"
);
byte[] encodedSignature = sgn.GetEncodedPKCS7(
hash, sap.SignDate, null, null, null, CryptoStandard.CMS
);
*/
byte[] paddedSignature = new byte[SIG_BUFFER];
Array.Copy(encodedSignature, 0, paddedSignature, 0, encodedSignature.Length);
var pdfDictionary = new PdfDictionary();
pdfDictionary.Put(
PdfName.CONTENTS,
new PdfString(paddedSignature).SetHexWriting(true)
);
sap.Close(pdfDictionary);
So right now I'm not sure if I'm messing up hashing part, signature part, or both. In signature code snippet above and in client code (not shown) I'm calling what I think is signature verification code, but that may be wrong too, since this is a first for me. Get the infamous "Document has been altered or corrupted since it was signed" invalid signature message when opening the PDF.
Client-side code (not authored by me) can be found here. Source has a variable naming error, which was corrected. For reference, CAPICOM documentation says signed response is in PKCS#7 format.
EDIT 2015-03-12:
After some nice pointers from #mkl and more research, it seems CAPICOM is practicably unusable in this scenario. Although not documented clearly, (what else is new?) according to here and here, CAPICOM expects a utf16 string (Encoding.Unicode in .NET) as input to create a digital signature. From there it either pads or truncates (depending which source in previous sentence in correct) whatever data it receives if the length is an odd number. I.e. signature creation will ALWAYS FAIL if the Stream returned by PdfSignatureAppearance.GetRangeStream() has a length that is an odd number. Maybe I should create an I'm lucky option: sign if ranged stream length is even, and throw an InvalidOperationException if odd. (sad attempt at humor)
For reference, here's the test project.
EDIT 2015-03-25:
To close the loop on this, here's a link to a VS 2013 ASP.NET MVC project. May not the be best way, but it does provide a fully working solution to the problem. Because of CAPICOM's strange and inflexible signing implementation, as described above, knew a possible solution would potentially require a second pass and a way to inject an extra byte if the return value of PdfSignatureAppearance.GetRangeStream() (again, Stream.Length) is an odd number. I was going to try the long and hard way by padding the PDF content, but luckily a co-worker found it was much easier to pad PdfSignatureAppearance.Reason. Requiring a second pass to do something with iText[Sharp], is not unprecedented - e.g. adding page x of y for a document page header/footer.
Use of PdfPkcs7
The server-side code contains this block after the calculation of the range stream digest and before forwarding data to the web page:
PdfPKCS7 sgn = new PdfPKCS7(
null, chain, DigestAlgorithms.SHA256, true
);
byte[] preSigned = sgn.getAuthenticatedAttributeBytes(
hash, sap.SignDate, null, null, CryptoStandard.CMS
);
var hashedValue = Convert.ToBase64String(preSigned);
In the case at hand this is not necessary. It is needed only if the external signing API you use merely returns a signed digest; in that case the PdfPKCS7 instance builds the CMS/PKCS#7 signature container. You, on the other hand, use an API for which you know
CAPICOM documentation says signed response is in PKCS#7 format.
Thus, you don't need and (more to the point) must not use the PdfPKCS7 instance.
What does sign.js sign
The content of the server-side hash variable already is the hash digest value of the data to sign. Thus, the frontend, i.e. the sign.js used there, must not hash it again to get the message digest attribute value to put into the signature.
But sign.js signing methods for IE eventually execute
var signedData = new ActiveXObject("CAPICOM.SignedData");
// Set the data that we want to sign
signedData.Content = src;
SignedData.Content, on the other hand, is documented as
Content Read/write Data to be signed.
(msdn: "SignedData object")
So the hash from the backend is used as data to be signed and not as hash of the data to be signed, you indeed hash twice and so have the wrong hash value there.
Thus, it looks like you have to transmit the whole ranged stream which is not really practical...
"But there used to be signing samples using CAPICOM..."
Indeed some old iTextSharp (version 4.x) signing example used CAPICOM. But that code only worked because it created signatures of PDF signature type adbe.pkcs7.sha1 for which a SHA1 hash of the ranged stream indeed is the data embedded in and signed by the PKCS#7 signature.
This is no real option anymore because
it requires the use of SHA1 which in serious contexts is invalid, and
its use has been discouraged at least since ISO 32000-1 (2008) and will be officially deprecated in ISO 32000-2 (under development).

Sign PDF using an external service and iText

I have this scenario.
I have an application that generates a PDF, and that needs to be signed.
We have not the certificates to sign the document, because they're in a HSM, and the only way we could make use of the certificates is using a webservice.
This webservice, offers two options, send the PDF document, and it returns a signed pdf, or send a hash that will be signed.
The first option, is not viable, because the PDF is signed without a timestamp (this is a very important requisite), so the second option is chosen.
This is our code, first, we get the signature appearance, and calculate the hash:
PdfReader reader = new PdfReader(Base64.decode(pdfB64));
reader.setAppendable(true);
baos = new ByteArrayOutputStream();
PdfStamper stamper = PdfStamper.createSignature(reader, baos, '\0', null, true);
appearance = stamper.getSignatureAppearance();
appearance.setCrypto(null, chain, null, PdfSignatureAppearance.SELF_SIGNED);
appearance.setVisibleSignature("Representant");
cal = Calendar.getInstance();
PdfDictionary dic = new PdfDictionary();
dic.put(PdfName.TYPE, PdfName.SIG);
dic.put(PdfName.FILTER, PdfName.ADOBE_PPKLITE);
dic.put(PdfName.SUBFILTER, new PdfName("adbe.pkcs7.detached"));
dic.put(PdfName.M, new PdfDate(cal));
appearance.setCryptoDictionary(dic);
HashMap<PdfName, Integer> exc = new HashMap<PdfName, Integer>();
exc.put(PdfName.CONTENTS, Integer.valueOf(reservedSpace.intValue() * 2 + 2));
appearance.setCertificationLevel(1);
appearance.preClose(exc);
AbstractChecksum checksum = JacksumAPI.getChecksumInstance("sha1");
checksum.reset();
checksum.update(Utils.streamToByteArray(appearance.getRangeStream()));
hash = checksum.getByteArray();
In this point, we have the hash code of the document. Then we send the hash to the webservice, and we get the signed hash code.
Finally, we put the signed hash to the PDF:
byte[] paddedSig = new byte[reservedSpace.intValue()];
System.arraycopy(signedHash, 0, paddedSig, 0, signedHash.length);
PdfDictionary dic = new PdfDictionary();
dic.put(PdfName.CONTENTS, new PdfString(paddedSig).setHexWriting(true));
appearance.close(dic);
byte[] pdf = baos.toByteArray();
In this point, we get a PDF signed, but with an invalid signature. Adobe says that "Document has been altered or corrupted since it was signed".
I think that we make something wrong in the process, and we don't know exactly what could be.
We appreciate help on this, or an alternative way to do that.
Thanks.
EDITED
As suggested by mkl, I have followed the 4.3.3 section of this book Digital Signatures for PDF documents, and my code now what that follows:
The first part, when we calculate the hash:
PdfReader reader = new PdfReader(Base64.decode(pdfB64));
reader.setAppendable(true);
baos = new ByteArrayOutputStream();
PdfStamper stamper = PdfStamper.createSignature(reader, baos, '\0');
appearance = stamper.getSignatureAppearance();
appearance.setReason("Test");
appearance.setLocation("A casa de la caputeta");
appearance.setVisibleSignature("TMAQ-TSR[0].Pagina1[0].DadesSignatura[0].Representant[0]");
appearance.setCertificate(chain[0]);
PdfSignature dic = new PdfSignature(PdfName.ADOBE_PPKLITE, PdfName.ADBE_PKCS7_DETACHED);
dic.setReason(appearance.getReason());
dic.setLocation(appearance.getLocation());
dic.setContact(appearance.getContact());
dic.setDate(new PdfDate(appearance.getSignDate()));
appearance.setCryptoDictionary(dic);
HashMap<PdfName, Integer> exc = new HashMap<PdfName, Integer>();
exc.put(PdfName.CONTENTS, new Integer(reservedSpace.intValue() * 2 + 2));
appearance.preClose(exc);
ExternalDigest externalDigest = new ExternalDigest()
{
public MessageDigest getMessageDigest(String hashAlgorithm) throws GeneralSecurityException
{
return DigestAlgorithms.getMessageDigest(hashAlgorithm, null);
}
};
sgn = new PdfPKCS7(null, chain, "SHA256", null, externalDigest, false);
InputStream data = appearance.getRangeStream();
hash = DigestAlgorithms.digest(data, externalDigest.getMessageDigest("SHA256"));
cal = Calendar.getInstance();
byte[] sh = sgn.getAuthenticatedAttributeBytes(hash, cal, null, null, CryptoStandard.CMS);
sh = MessageDigest.getInstance("SHA256", "BC").digest(sh);
hashPdf = new String(Base64.encode(sh));
And in the second part, we get the signed hash, and we put that into the PDF:
sgn.setExternalDigest(Base64.decode(hashSignat), null, "RSA");
byte[] encodedSign = sgn.getEncodedPKCS7(hash, cal, null, null, null, CryptoStandard.CMS);
byte[] paddedSig = new byte[reservedSpace.intValue()];
System.arraycopy(encodedSign, 0, paddedSig, 0, encodedSign.length);
PdfDictionary dic2 = new PdfDictionary();
dic2.put(PdfName.CONTENTS, new PdfString(paddedSig).setHexWriting(true));
appearance.close(dic2);
byte[] pdf = baos.toByteArray();
Now, Adobe raises a Internal Cryptographic library error. Error Code: 0x2726, when we try to validate the signature.
If the web service returned a mere signed hash
In this point, we have the hash code of the document. Then we send the hash to the webservice, and we get the signed hash code.
Finally, we put the signed hash to the PDF:
If the webservice merely returns a signed hash, then your PDF signature is incorrect: You set the signature SubFilter to adbe.pkcs7.detached. This implies that the signature Contents have to contain a full-blown PKCS#7 signature container, not merely a signed hash.
You might want to download Digital Signatures for PDF documents, A White Paper by Bruno Lowagie (iText Software) on creating and verifying digital PDF signatures using iText. It especially contains a section "4.3 Client/server architectures for signing" which should encompass your use cases.
But the web service returns a full-fledged CMS signature container
Following to the explanation above, the OP started using code from section 4.3.3 of the above-mentioned white paper which is intended for signing using externally generated signed hashes. As this also resulted in a signed document Adobe Reader was not happy with, he provided a sample document created with this new code.
Analysis of the sample showed that the CMS signature container embedded in the document contained another CMS signature container where there should have been the signature bytes (the signed hash) for the signed attributes:
2417 13: SEQUENCE {
2419 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
2430 0: NULL
: }
2432 5387: OCTET STRING, encapsulates {
2436 NDEF: SEQUENCE {
2438 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
2449 NDEF: [0] {
2451 NDEF: SEQUENCE {
(The OCTET STRING following the signature algorithm should contain the signature bytes and not embed another SignedData structure.)
This indicates that the web service indeed already returns a full-fledged CMS container.
For such a scenario the original code looked quite ok. The issue might be due to a detail like the use of a wrong hashing algorithm (the original code hashed using SHA1).
A possible issue: BER encoding
The CMS signature container from the web service embedded in the CMS container generated by iText from the first sample provided by the OP hints at a possible issue: Looking at the ASN.1 dump above the sizes of the outer structures in the embedded CMS container are often NDEF.
This indicates that these outer structures are created using the less strict BER (Basic encoding Rules), not the more strict DER (Distinguished Encoding Rules) because the BER option to start a structure without stating its size is forbidden in DER.
The CMS specification (RFC 3852) referenced from the PDF specification does allow any BER encoding for the outer structures of the container, the PDF specification on the other hand requires:
the value of Contents shall be a DER-encoded PKCS#7 binary data
object containing the signature. The PKCS#7 object shall conform to RFC3852 Cryptographic Message Syntax.
Strictly speaking, therefore, signature containers embedded in PDFs are required to be DER encoded all over.
As far as I know no PDF signature validator rejects such signatures as long as the signature container DER-encodes certain pivotal elements. Concerning future tools such signatures are a possible point of failure, though.
After much debugging, we finally found the problem.
For some mysterious reason, the method that generates the hash of the document, was executed twice, invalidating the first hash (which we use to send to the service).
After a refactoring work of the code, the original code worked correctly.
Very thanks to all people that help me, especially mkl.

How do I get the browser to prompt "Open / Save" when this stream is returned?

I'm using Crystal Reports and have some code that returns a stream of a PDF report. When The report is done being generated, the browser (IE8) prompts for the user to open or save the report. It works but behind the scenes an exception is being thrown. We handle the exception but the handling causes some other problems.
// This completes but throws an exception.
rpt.ExportToHttpResponse(crExportOptions.ExportFormatType, resp, true, fileName);
The solution according to a post on the SAP site works and the exception is no longer thrown. However, the problem is we no longer have the option to open or save the file. The report is just opened in the browser.
System.IO.Stream oStream = null;
byte[] byteArray = null;
oStream = report.ExportToStream(crExportOptions.ExportFormatType);
byteArray = new byte[oStream.Length];
oStream.Read(byteArray, 0, Convert.ToInt32(oStream.Length - 1));
response.ClearContent();
response.ClearHeaders();
response.ContentType = "application/pdf";
response.BinaryWrite(byteArray);
response.Flush();
response.Close();
report.Close();
report.Dispose();
I want my cake and I want to eat it! I don't want the exception thrown (solved by the SAP solution) but still want the option to open or save the PDF returned. How do I modify the above code the present the user with the option to save / open?
Thanks!
Found a solution in this SO post.
added this to my code...
response.AddHeader("Content-Disposition", string.Format("attachment; filename={0}", reportName));