I programmatically created a PDF with object streams and encryption, but while several PDF viewers can read it, some fail.
PDF readers, which can read it:
Foxit
Google Chrome
Nuance
Nitro
pdf.js
PDF readers, which cannot read it:
Adobe Reader
PDF X/Change
Currently i am blind to see, what the problem inside the PDF is. Can anyone help? The PDF can be downloaded at https://www.doxisafe.me/#!/retrieve/ivqkli
The PDF is encrypted with an owner password "owner" and no user password.
Today i found a solution, that Adobe just requires the Catalog dictionary not to be in an object stream, when the file is encrypted. This is not following the pdf spec, which claims, that only the following objects shouldn't be inside the object stream:
Stream objects
Objects with a generation number other than zero
A document’s encryption dictionary (see 7.6, "Encryption")
An object representing the value of the Length entry in an object stream dictionary
In linearized files (see Annex F), the document catalog, the linearization dictionary, and page objects shall not appear in an object stream.
My file is not linearized, so the last condition shall not apply.
Related
I have a banking client for whom I have designed an iOS app where we will populate all the client details onto the account opening application pdf forms and generate the final pdf with all the client details. I am generating a pdf using CoreGraphics. But the pdf is editable in Adobe Acrobat Pro and they are able to edit the contents of the application form. Is there any method to restrict the editing of the pdf after it is generated from CoreGraphics? I have encrypted the pdf with a password But the client needs the pdf to be non editable.
See Protecting PDF Content
Reading between the lines a bit — because the docs are not overly clear — I think that when you create the PDF context using CGPDFContextCreate(), you pass a dictionary into its auxiliaryInfo, using the key kCGPDFContextOwnerPassword and a value that's some arbitrary password string. This encrypts the document so that only the owner (there people with that password) can work with the contents. It doesn't say it prevents editing explicitly, but I'm guessing that's implied because it list out special keys to block printing and copying (preventing editing seems like the thing one would always want when encrypting a pdf).
I want to merge several PDF documents into one. The source documents can consist of PDFs created by me and others created by other organisations. I have no control over the permissions attached to documents not created by me. Some of these documents (those not created by me) may have permissions set. If a document requires a password to open it I do not attempt to merge it.
I am using iText 5.5.1 (I think that is the latest) to create a PDFCopy object to contain the resulting document and a reader for each source PDF in a loop (I am passing a list of the documents to be merged). I check each document for the number of pages and then using the PDFCopy object import each page and then add it to the PDFCopy object (the reason these two steps are separate is due to the intricacies of the language I am using to work with the java objects, RPG on an IBM iSeries). The problem is I can attach a reader to a PDF with permissions and get the page count, but as soon as I try to import a page into the copy object the program complains and terminates with the message 'PdfReader not opened with owner password'. I am not able to get the person(s) providing the documents from other organisations to not protect the documents (there a very, very good reasons why the original document is protected from change) but I need to consolidate these documents into one.
My question is, can I copy PDF's with permissions into a new document using iText and can I do it without knowing the owner password? In addition to that I guess the other question would be, is it legal?
Thanks
GarryM
Introduction: A PDF file can be encrypted using a public certificate. If you have such a PDF, you need the corresponding private certificate to decrypt it. A PDF file can be encrypted using two passwords: a user password and an owner password. If the PDF is encrypted using a user password, you need at least one of the two passwords to decrypt it.
Assumption: I assume that the PDFs are encrypted with nothing but an owner password. You can open these documents in a PDF viewer without having to provide a user password, which means the content can be accessed, but there are some restrictions in place depending on the permissions that are set.
Situation: iText is a library that allows you to access PDFs at a very low level, without a GUI. It can easily access a PDF that is encrypted with nothing but an owner password, but it can't check if you respect the permissions that are defined for the PDF. To make sure that you are aware of your responsibilities, an exception is thrown saying PdfReader not opened with owner password. This is often too strict: sometimes you have the permission to assemble a PDF file, but with iText it's all or nothing. Either you can open the file, or you can't. iText doesn't check what you're doing afterwards.
Solution: There is a static Boolean parameter called unethicalreading that is set to false by default. You can change it like this:
PdfReader.unethicalreading = true;
--EDIT (since iText 7):
pdfReader.setUnethicalReading(true);
From now on, it will be as if the PDFs aren't encrypted.
Is this legal? It's not that clear and I am not a lawyer, but:
It used to be illegal when Adobe still owned the copyright on the PDF specification. Adobe granted the right to use that copyright to any developer on certain conditions. One of these conditions was that you didn't "crack" a PDF. Removing the password from a PDF broke your "contract" with Adobe to use the PDF specification and you risked being sued.
This changed when Adobe donated the PDF specification to the community in order to make it an ISO standard. Now every one can use this international standard, and the above (risk of being sued by Adobe for infringing the copyright) no longer exists.
As the ISO standard documents the mechanism of encryption with an owner password and it is very easy to use the ISO standard to decrypt a document without having that password, the concept of introducing an owner password to enforce permissions is flawed from a technical point of view. It's merely a psychological way to prevent people to do something with your document that you, as an author, do not want.
It's like a stop sign on a deserted road. It says: you should stop here, but nobody/nothing is going to stop you if no one is around.
Suggested approach:
My approach is to decrypt the PDF using the unethicalreading parameter, and to look at the permissions that are set. If the permissions don't allow assembly, I refuse the document. I also set permissions on the resulting PDF where I try to find the combination of permissions that respect the permissions set on the original documents.
In some cases, it's not that hard: the people don't know the PDFs are often the owners of the documents who forgot the passwords that were used to encrypt them. In that case, simple permission of the owners of the documents is sufficient to decrypt them.
Final remark: I'm the original developer of iText and I'm responsible for introducing the unethicalreading parameter. I've chosen the name unethicalreading only to make sure people are aware of what they are doing. It doesn't mean that using that parameter is always unethical or illegal.
I am using iTextSharp & pkcs11RsaSignature to insert digital signature on every page of PDF document. following is my code:
PdfReader pdfSource = new PdfReader(...);
NumberOfPages = pdfSource.NumberOfPages;
pdfSource.Close();
CurrentPage = 1;
while (CurrentPage <= NumberOfPages)
{
Temp3PDF = Temp1PDF;
Temp1PDF = Temp2PDF;
Temp2PDF = Temp3PDF;
PdfReader pdfSrc = new PdfReader(Temp1PDF);
FileStream pdfDes = new FileStream(Temp2PDF, FileMode.Create);
PdfStamper pdfStamper = PdfStamper.CreateSignature(pdfSrc, pdfDes, '\0', Path.GetTempFileName(), true);
PdfSignatureAppearance pdfSignAppearance = pdfStamper.SignatureAppearance;
pdfSignAppearance.Acro6Layers = false;
pdfSignAppearance.SetVisibleSignature(new iTextSharp.text.Rectangle(100, 100, 250, 150), CurrentPage, null);
MakeSignature.SignDetached(pdfSignAppearance, pkcs11RsaSignature, certPath, null, null, null, 0, CryptoStandard.CADES);
pdfStamper.Close();
pdfDes.Close();
pdfSrc.Close();
CurrentPage++;
}
As can be seen, this is NOT a very elegant way of programming as file is read and written as many times as number of pages. Is there any other way of inserting digital signature on every page of PDF document.
What is actually wanted to do here is that - in case the PDF document is split into pages (in future), since the contents haven't changed, so technically digital signature should be valid for the pages it is signed. But I realize the signature will get invalidated. (Rephrasing the question - Is there any way of digitally signing only one page of pdf and not entire document?)
To Bruno Lowagie (you are expert) : Except that it is not provided in PDF specification, it is possible to partially sign a PDF file by signing the hash computed only on selected components. Do you think it is possible to upgrade PDF specifications to accommodate such requirement. Thank you for your help.
What is actually wanted to do here is that - in case the PDF document is split into pages (in future), since the contents haven't changed, so technically digital signature should be valid for the pages it is signed.
This train of thought is based on a misconception. Yes, you have the visualization of the signature on one specific page, but cryptographically the signature signs the whole PDF with the sole exception of the embedded CMS signature container itself.
But you found out about this yourself. Thus, let's consider your rephrased question:
But I realize the signature will get invalidated. (Rephrasing the question - Is there any way of digitally signing only one page of pdf and not entire document?)
In the past there had been two ways which might have allowed to sign single pages:
using an object digest focusing on the page in question;
using a byte range digest only consisting of byte ranges covering objects related to the page in question.
Nowadays, though, these techniques are not usable options anymore because
object digests have been deprecated a long time ago, the ISO PDF specification does not even mention them anymore;
even though ISO 32000-1 still allows byte range digests to cover such a collection of fragments of the PDF, PDF processors (in particular Adobe Reader) require the byte ranges to cover the whole PDF file with the sole exception of the embedded signature container; newer specifications (e.g. the ETSI PAdES specifications and the ISO 32000-2 drafts) also require this.
Thus, no, there is no way of digitally signing only one page of pdf and not entire document, at least not in an interoperable manner.
An option for achieving something similar as page-wise signatures in a multi-page PDF would be to
split the PDF into multiple PDFs, each containing a single page only;
signing each of these single page PDFs; and
putting all these single-page PDFs into a PDF portable collection (aka portfolio) and arranging it to display the individual contained PDFs one after the other in the correct order.
I want to merge several PDF documents into one. The source documents can consist of PDFs created by me and others created by other organisations. I have no control over the permissions attached to documents not created by me. Some of these documents (those not created by me) may have permissions set. If a document requires a password to open it I do not attempt to merge it.
I am using iText 5.5.1 (I think that is the latest) to create a PDFCopy object to contain the resulting document and a reader for each source PDF in a loop (I am passing a list of the documents to be merged). I check each document for the number of pages and then using the PDFCopy object import each page and then add it to the PDFCopy object (the reason these two steps are separate is due to the intricacies of the language I am using to work with the java objects, RPG on an IBM iSeries). The problem is I can attach a reader to a PDF with permissions and get the page count, but as soon as I try to import a page into the copy object the program complains and terminates with the message 'PdfReader not opened with owner password'. I am not able to get the person(s) providing the documents from other organisations to not protect the documents (there a very, very good reasons why the original document is protected from change) but I need to consolidate these documents into one.
My question is, can I copy PDF's with permissions into a new document using iText and can I do it without knowing the owner password? In addition to that I guess the other question would be, is it legal?
Thanks
GarryM
Introduction: A PDF file can be encrypted using a public certificate. If you have such a PDF, you need the corresponding private certificate to decrypt it. A PDF file can be encrypted using two passwords: a user password and an owner password. If the PDF is encrypted using a user password, you need at least one of the two passwords to decrypt it.
Assumption: I assume that the PDFs are encrypted with nothing but an owner password. You can open these documents in a PDF viewer without having to provide a user password, which means the content can be accessed, but there are some restrictions in place depending on the permissions that are set.
Situation: iText is a library that allows you to access PDFs at a very low level, without a GUI. It can easily access a PDF that is encrypted with nothing but an owner password, but it can't check if you respect the permissions that are defined for the PDF. To make sure that you are aware of your responsibilities, an exception is thrown saying PdfReader not opened with owner password. This is often too strict: sometimes you have the permission to assemble a PDF file, but with iText it's all or nothing. Either you can open the file, or you can't. iText doesn't check what you're doing afterwards.
Solution: There is a static Boolean parameter called unethicalreading that is set to false by default. You can change it like this:
PdfReader.unethicalreading = true;
--EDIT (since iText 7):
pdfReader.setUnethicalReading(true);
From now on, it will be as if the PDFs aren't encrypted.
Is this legal? It's not that clear and I am not a lawyer, but:
It used to be illegal when Adobe still owned the copyright on the PDF specification. Adobe granted the right to use that copyright to any developer on certain conditions. One of these conditions was that you didn't "crack" a PDF. Removing the password from a PDF broke your "contract" with Adobe to use the PDF specification and you risked being sued.
This changed when Adobe donated the PDF specification to the community in order to make it an ISO standard. Now every one can use this international standard, and the above (risk of being sued by Adobe for infringing the copyright) no longer exists.
As the ISO standard documents the mechanism of encryption with an owner password and it is very easy to use the ISO standard to decrypt a document without having that password, the concept of introducing an owner password to enforce permissions is flawed from a technical point of view. It's merely a psychological way to prevent people to do something with your document that you, as an author, do not want.
It's like a stop sign on a deserted road. It says: you should stop here, but nobody/nothing is going to stop you if no one is around.
Suggested approach:
My approach is to decrypt the PDF using the unethicalreading parameter, and to look at the permissions that are set. If the permissions don't allow assembly, I refuse the document. I also set permissions on the resulting PDF where I try to find the combination of permissions that respect the permissions set on the original documents.
In some cases, it's not that hard: the people don't know the PDFs are often the owners of the documents who forgot the passwords that were used to encrypt them. In that case, simple permission of the owners of the documents is sufficient to decrypt them.
Final remark: I'm the original developer of iText and I'm responsible for introducing the unethicalreading parameter. I've chosen the name unethicalreading only to make sure people are aware of what they are doing. It doesn't mean that using that parameter is always unethical or illegal.
I need to make an incremental update (add some existing pdf pages) to an signed pdf, making the included signature still be valid (that cover the first page).
I've seen some post's telling that is possible with PDFStamper (iTextSharp), but I'm unable to find a example out to make it append.
Changing an already signed PDF would sound imply a security leak in the PDF signing functionality/spec. The purpose of signing a PDF is a guarantee to the reader that it has not been altered by anyone other than the original author.
I think your only option is to send extra pages in a seperate PDF, or change the original PDF and have it re-signed.