Implementation flaws in Adobe Document Server for Reader Extensions
Vladimir Katalov
============================================================================
===
Free Adobe Acrobat Reader (version 5.1 or later) has ability to: add notes
and
attachments, add and check digital signatures, save forms locally, fill them
out online, distribute to others for review and commenting, and submit forms
via e-mail or the Web directly from within Acrobat Reader. But actions
listed
above available for rights-enabled documents only (i.e. documents processed
by Adobe Document Server for Reader Extensions). Improper usage of
cryptography
in server software allows anyone to produce reader-enabled documents without
Document Server for Reader Extensions.
Contact information
============================================================================
===
Name : ElcomSoft Co.Ltd.
WWW : http://www.elcomsoft.com/company.html
E-mail : in...@elcomsoft.com
Fax : +1 866 448-2703 (US/Canada, toll-free)
The problem has been reported to vendor (Adobe Systems Inc) on
02/24/2003; vendor has not replied.
Technical info
============================================================================
===
Adobe Document Server for Reader Extensions
----------------------------------------------------------------------------
---
With this server, customers can assign custom usage rights to specific Adobe
Portable Document Format (PDF) forms and documents, so Acrobat Reader 5.1
users
can get access to additional features while working with the document. The
server can enable four types of usage rights on a PDF form:
- Commenting tools, including sticky notes, highlights, stamps, and
strikethroughs;
- The ability to save a form to a desktop for offline completion or
archiving,
without loosing any forms data;
- Digital signatures, including support for Public Key Infrastructure
systems
for third-party validation (VeriSign, Entrust, and others);
- Advanced form features, including the ability to submit a form offline or
via
email, import or export forms data and attached files.
Description of Adobe Document Server for Reader Extensions features is
available at
http://www.adobe.com/products/server/readerextensions/main.html.
The implementation of Document Server for Reader Extensions does not seem to
be
very complicated. The Server just gets the PDF file (to be reader-enabled)
together with the list of enabling options, and produces new document that
contains one additional dictionary - actually, simply by adding an
additional
block of data.
Note: for details of PDF structure, see Portable Document Format
Specification
http://partners.adobe.com/asn/developer/acrosdk/docs/filefmtspecs/PDFReferen
ce.pdf
New dictionary is named "ViewerPreferences" and resides within document's
"Root" dictionary. For now, only one element is placed inside
"ViewerPreferences" dictionary - "Rights" Dictionary. Content of the
"Rights"
Dictionary can be described as follows (key name, type and description):
"Version" (number): A number specifying the version of Rights dictionary.
Currently only version 1 is supported.
"Document" (array of names): List of flags related to Document operations.
Currently only one flag is supported: FullSave.
"Form" (array of names): List of flags related to Form processing. Supported
flags: Import, Export, SubmitStandalone, SpawnTemplate.
"Annots" (array of names): List of flags related to Annotations. Supported
flags: Create, Delete, Modify, Copy, Import, Export.
"Signature" (array of names): List of flags related to Digital Signature
handling. Currently only one flag is supported: Modify.
"Msg" (text string): Arbitrary string to be displayed in "Instructions" box
when reader-enabled document is opened in Acrobat Reader 5.1.
"TimeOfUbiquitization" (date): The date and time when document was processed
by Document Server for Reader Extensions.
"RightsID" or "ADBE_RightsID" (array): List of RSA-based digital signatures
for checking integrity of reader-enabling attributes.
Most elements listed in the table above are self-descriptive. Name of the
last
key could be either RightsID or ADBE_RightsID - they are equivalent in
Reader
5.1. Values in RightsID (or ADBE_RightsID) array are 512-bit RSA-encrypted
values, and could be decrypted with RSA Public Key, which is hard-coded (in
encrypted form) within Reader 5.1 executable. Those values are used as
digital
signatures of some critical document parts to make sure that document was
reader-enabled with Adobe Document Server for Reader Extensions.
Sample form with additional usage rights could be downloaded from
http://www.adobe.com/products/server/readerextensions/pdfs/sample_docserver_
readerext.pdf
According to press release from October 21, 2002, available at
http://www.adobe.com/aboutadobe/pressroom/pressreleases/pdfs/200210/20021021
Ubiquity.pdf,
pricing of Adobe Document Server for Reader Extensions starts at US$75,000.
Adobe Acrobat Reader
----------------------------------------------------------------------------
---
Adobe Acrobat Reader is the most popular part of Adobe Acrobat product
family.
Acrobat Reader is free and can be downloaded from Adobe Systems Incorporated
web site http://www.adobe.com/products/acrobat/readermain.html.
Other most interesting (for this statement) products from Adobe Acrobat
family
are commercial Adobe Acrobat ($249) and Adobe Acrobat Approval ($39).
Comparison
of the free Acrobat Reader 5.1 with Acrobat 5.0 and Acrobat Approval could
be
found at Planet PDF web site:
http://www.planetpdf.com/mainpage.asp?webpageid=2413.
For a long time Acrobat Reader was just "the reader" - its ability of
editing
was limited to form filling, but there was no way to get altered copy of the
document on disk. Acrobat Reader 5.1, however, includes some new functions,
that extend Reader functionality, and make it very close to commercial
Acrobat
Approval. In other words, new Acrobat Reader 5.1 is something like a limited
version of Acrobat Approval with functional restrictions applied to
all documents except reader-enabled ones.
When the document is opened in Acrobat Reader 5.1, the Reader looks inside
ViewerPreferences/Rights dictionary, and based on information found there,
enables some editing features (or keep them disabled).
The problem
----------------------------------------------------------------------------
---
As noted earlier, 512-bit RSA encryption is being used to prevent creating
reader-enabled documents without Adobe Document Server for Reader
Extensions.
512-bit RSA keys are not considered to be absolutely non-breakable - in 1999
a group of researchers completed the factorization of the 512-bit RSA
Challenge Number in 5.2 months (see
http://www.rsasecurity.com/rsalabs/challenges/factoring/rsa155.html for
details). But it seems that building a system for breaking RSA-512 is more
expensive than obtaining Document Server for Reader Extensions from Adobe.
So, 512-bit RSA is sufficient for such application. But, as it often
happens,
implementation corrupts the idea.
"RightsID" key from "Rights" Dictionary usually contains three values. First
value is a signature for the "Rights" Dictionary content (excluding
"RightsID"/"ADBE_RightsID" key itself), "CreationDate", "Producer" and
"Creator" keys from PDF Info Dictionary, and Document ID from PDF Trailer
Dictionary. Second and third values from "RightsID" key are signatures of
the
first and the last pages of PDF document content, respectively.
The document is considered to be enabled properly only when the "Rights"
Dictionary signature and at least one Page Content signature are correct.
Let's starts the research with page content signature calculation.
At the first stage, every byte of decompressed page content (but not more
than
1024 bytes) is passed through the hash function. Hash is not too
complicated -
some non-printable characters (such as Space, Tab, CR, LF) are ignored, and
ASCII-codes of all remaining characters are added to 32-bit counter,
initially
set to zero.
At the second stage, the 32-bit value calculated as described above
(actually, the largest possible value contains only 18 significant
bits) is converted to 8-byte hexadecimal representation, and "PaGeS" string
is
appended to the end. Resulting 13-byte sequence is processed with MD5 hash
function, which produces 128-bit (16-byte) page fingerprint.
At the last stage, 512-bit RSA Private Key (stored somewhere in Server) is
used
to encrypt page fingerprint. Encrypted value is stored in "RightsID" array.
To
verify Page Content signature, the Reader calculates page fingerprint and
compares it with the value decrypted using RSA Public Key.
Obviously, the signature calculation procedure described above is not
perfect.
Adding "PaGeS" string does not affect the reliability at all. But it is
looks
like a sort of tradition in Adobe: in undocumented version of key
calculation
algorithm (V3), used by Standard Security Handler in Adobe Acrobat 5, string
"sAlT" has been used in the same way - instead of the real "salt" value,
that
should be totally random.
But the most significant problem with Page Content signature calculation is:
it
is very easy to build 1024-byte sequence of characters, treated as comments
by
PDF interpreter, so the sum of all characters in that sequence will be the
same
as the sum of first 1024 characters in any reader-enabled document. So,
inserting such comment before any page will produce a new page, interpreted
exactly like original one, with fixed (known) signature value.
Let's pay some attention to the "Rights" Dictionary signature calculation.
During that operation, some 32-bit hash (not cryptographic one, but a little
bit more complicated than just addition) is calculated from all keys of the
"Rights" Dictionary excluding "RightsID" array. Hash value is converted to
hexadecimal representation and passed through MD5 hash function along with
the values from PDF Info Dictionary such as "CreationDate", "Producer" and
"Creator", and constant string "Adobe Acrobat". First five bytes of MD5
output
are treated as a key for RC4 symmetric stream cipher, which is used to
encrypt
Document ID from PDF Trailer Dictionary. Encrypted ID is encrypted again
with
RSA Private Key to produce "Rights" Dictionary signature that should be
stored
as the first element of the "RightsID" array.
This procedure looks not too bad in comparison with Page Content signature
calculation, but not perfect too. Now, the problem is related to Document ID
and RC4. It is well known that RC4 (like many other stream ciphers) is just
a pseudo-random sequence generator, and generated stream is combined with
source data by XOR operation to produce encrypted data. Therefore, if we
need
to force "Rights" Dictionary signature to be equal to some predefined value,
the following approach should work:
- Decrypt signature (from any reader-enabled document) by RSA Public Key to
obtain RC4-encrypted Document ID;
- Calculate "Rights" Dictionary and Info Dictionary hash (from document to
be
reader-enabled) to obtain RC4 key;
- Decrypt Document ID value by RC4 and assign it to the new document.
It is necessary to note that Document ID consists of two parts: permanent
identifier and variable identifier. Only permanent identifier is involved in
the signature calculation. The Document ID is used to resolve external
references by ID, and almost useless in "standalone" documents. So,
assigning
the new Document ID is not a big issue.
Impact
============================================================================
===
As it was shown above, all 512-bit RSA-based signature checks could be
easily
bypassed - it is very difficult to break RSA-512 cipher itself and calculate
signature values for arbitrary document, but it is much easier to modify
document to match a fixed (known) signature values without noticeable
changes
in the document's content, and without breaking, stealing or purchasing RSA
private key.
It is looks like the only party negatively affected by such facts is Adobe
Systems Incorporated itself. But if some U.S. government agency will decide
to
spend $75K for Adobe Document Server for Reader Extensions, all U.S.
taxpayers
will be affected by indirection, too.
Conclusion
============================================================================
===
It is not too hard to guess why Adobe Document Server for Reader Extensions
has
been introduced. Generally, there are two main reasons - Government
Paperwork
Elimination Act (GPEA), U.S. federal agencies must adhere by October 2003
to;
and recently announced Microsoft InfoPath (formerly code-named "XDocs"),
which
promises to become the main competitor for PDF Forms and Adobe Acrobat
products family. And efforts to seizure market niche as soon as possible in
this case obviously leads to bad design and implementation flaws in
cryptography-based operations.
This issue does not deal with security, but deals with cryptography, that is
widely used to provide security. Using of modern cryptography (RSA, RC4,
MD5)
cannot guarantee that the information is secured properly. And even if big
companies do not have enough resources to hire competent
security/cryptography specialist, what should we expect from the market in
whole?
JR Boulay
like the Adobe sample form quoted in your posting) and Acrobat 5 menu
items for creating your own (free and perfectly legal) forms with
Extended rights enabled.
Without any programming or cryptographic knowledge...
It's a 7 years old child game.
But you can be proud, until now I just knew "how", not "why"...
I agree with you : these possibilities are deliberately wanted and
provided by Adobe.
As I'd claimed in a previous posting, few months ago : it was
inescapable... because it's obviously Abobe's own interest.
;-)
JRB
In <b46ufp$1rv3mv$1...@ID-89288.news.dfncis.de> Vladimir Katalov wrote:
> Summary
> ======================================================================
> ==
> ==== ===
>
> Free Adobe Acrobat Reader (version 5.1 or later) has ability to: add
> notes and attachments, add and check digital signatures, save forms
> locally, fill them out online, distribute to others for review and
> commenting, and submit forms via e-mail or the Web directly from
> within Acrobat Reader. But actions listed above available for rights-
> enabled documents only (i.e. documents processed by Adobe Document
> Server for Reader Extensions). Improper usage of cryptography in
> server software allows anyone to produce reader-enabled documents
> without Document Server for Reader Extensions.
>
> Contact information
> ======================================================================
> ==
> ==== ===
>
> Name : ElcomSoft Co.Ltd.
> WWW : http://www.elcomsoft.com/company.html
> E-mail : in...@elcomsoft.com
> Fax : +1 866 448-2703 (US/Canada, toll-free)
>
> The problem has been reported to vendor (Adobe Systems Inc) on
> 02/24/2003; vendor has not replied.
>
> Technical info
> ======================================================================
> ==
> ==== ===
> PDFReferen ce.pdf
> docserver_ readerext.pdf
>
> According to press release from October 21, 2002, available at
> http://www.adobe.com/aboutadobe/pressroom/pressreleases/pdfs/200210/
> 20021021 Ubiquity.pdf, pricing of Adobe Document Server for Reader
> excluding "RightsID"/"ADBE_RightsID" key itself), "CreationDate",
> ==== ===
>
> As it was shown above, all 512-bit RSA-based signature checks could be
> easily
> bypassed - it is very difficult to break RSA-512 cipher itself and
> calculate signature values for arbitrary document, but it is much
> easier to modify document to match a fixed (known) signature values
> without noticeable changes in the document's content, and without
> breaking, stealing or purchasing RSA private key.
>
> It is looks like the only party negatively affected by such facts is
> Adobe Systems Incorporated itself. But if some U.S. government agency
> will decide to spend $75K for Adobe Document Server for Reader
> Extensions, all U.S. taxpayers will be affected by indirection, too.
>
> Conclusion
> ======================================================================
> ==
> ==== ===
Max Khesin
privet,
--
========================================
Max Khesin, software developer -
m...@cNvOiSsPiAoMntech.com
[check out our image compression software at www.cvisiontech.com, JBIG2-PDF
compression @
www.cvisiontech.com/cvistapdf.html]
"Vladimir Katalov" <vkat...@elcomsoft.com> wrote in message
news:b46ufp$1rv3mv$1...@ID-89288.news.dfncis.de...