How can we check whether our Digital Signature on PDF is according to 'PAdES' standard ?
Best Regards
Pearapon S.
Bangkok, Thailand
The OP uses third-party software (iText 5.4.2 in the case at hand) for creating PAdES signatures and now wants to check whether the resulting signatures indeed satisfy the PAdES specification. Here some ideas for that:
What do you mean by "PAdES signature"?
First of all you have to define what you mean by "PAdES signature":
Do you mean that term as defined in the upcoming PDF 2.0 specification:
The PDF signatures using the Subfilter value ETSI.CAdES.detached are referred to as PAdES signatures and they follow one of two CMS profiles created to be compatible with the corresponding CAdES profiles defined in ETSI EN 319 122.
(ISO 32000-2 FDIS section 12.8.3.4 - CAdES signatures as used in PDF)
Do you mean more specifically a signature following one of the PAdES baseline signature profiles as specified in ETSI EN 319 142-1?
Clause 6 defines four levels of PAdES baseline signatures, intended to facilitate interoperability and to encompass the life cycle of PAdES signature, namely:
a) B-B level provides requirements for the incorporation of signed and some unsigned attributes when the signature is generated.
b) B-T level provides requirements for the generation and inclusion, for an existing signature, of a trusted token proving that the signature itself actually existed at a certain date and time.
c) B-LT level provides requirements for the incorporation of all the material required for validating the signature in the signature document. This level aims to tackle the long term availability of the validation material.
d) B-LTA level provides requirements for the incorporation of electronic time-stamps that allow validation of the signature long time after its generation. This level aims to tackle the long term availability and integrity of the validation material.
(ETSI EN 319 142-1 V1.1.1 section 6 - PAdES baseline signatures)
Or would one of the additional PAdES signatures profiles from ETSI EN 319 142-2 also qualify?
The present document contains a profile for the use of PDF signatures, as described in ISO 32000-1 [1] and based on CMS digital signatures [i.6], that enables greater interoperability for PDF signatures by providing additional restrictions beyond those of ISO 32000-1 [1]. This first profile is not related to ETSI EN 319 142-1 [4].
The present document also contains a second set of profiles that extend the scope of the profile in PAdES part 1 [5], while keeping some features that enhance interoperability of PAdES signatures. These profiles define three levels of PAdES extended signatures addressing incremental requirements to maintain the validity of the signatures over the long term, in a way that a certain level always addresses all the requirements addressed at levels that are below it. These PAdES extended signatures offer a higher degree of optionality than the PAdES baseline signatures specified in ETSI EN 319 142-1 [4].
The present document also defines a third profile for usage of an arbitrary XML document signed with XAdES signatures that is embedded within a PDF file.
(ETSI EN 319 142-2 V1.1.1 section 1 - Scope)
In particular you have to know whether you are also considering the additional PAdES signatures profiles "for CMS digital signatures in PDF" or "for XAdES Signatures signing XML content in PDF" from ETSI EN 319 142-2 or not because these two profiles differ very much from the remaining ones.
I assume you don't consider these two profiles because the former more or less is the good old ISO 32000-1 CMS signature with a few restriction most signers follow anyways, and the latter are XML signatures which are a completely different animal altogether.
All the remaining profiles differ mostly in the amount and type of validation related information and time stamps added to the document to make the validation less and less dependent on data one has to retrieve online.
Options for checking
Manually: You take a PDF browser (like iText RUPS or the PDFBox PDF Debugger), a hex viewer, an ASN.1 Dump utility, the applicable base specification from the list above and the additional specifications referenced from the base specification and check all the criteria.
This requires quite some time for a single signature but in the end you can know everything there is to know about the tested signature. I only recommend this if you have some experience using those tools and working with specifications, or if you really have much time to learn.
Programmatically: You take a general purpose PDF library (if you take a different one than the one you create you signatures with, the credibility of the result might increase), a security functions library (e.g. BouncyCastle), the base specification and the additional ones, and start implementing a program testing the criteria in the specification.
This requires quite some time to develop but then can be re-used, e.g. for quality assurance and regression prevention. I only recommend this if you have some experience using those libraries and working with specifications, or if you really have much time to learn.
You use an existing software or service that evaluates the signature for you, e.g. the ETSI Signature Conformance Checker (http://signatures-conformance-checker.etsi.org/pub/index.shtml), a free online tool that performs numerous checkings in order to verify the conformity of the ETSI Advanced Electronic Signatures.
This obviously is the quickest option but you generally cannot be sure how reliable the tests were executed. Thus, it is good as a first opinion but depending on how much is at stake, I would want more security.
You can hire experts to analyse and assess the validity of your signature according to the desired profile.
This may be expensive but at least you have someone to resort to if later you get into trouble due to some non-compliance.
Related
There are different standards for PDF files:
PDF/A: PDF/A-1a, PDF/A-2a or PDF/A-3a
PDF/UA
Potentially more
Is it possible to check if a given PDF file follows the PDF/UA standard?
Partially.
Most PDF based ISO standards (PDF/X, PDF/VT, PDF/E, PDF/VCR, PDF/A) can be automatically checked in software. I'm affiliated with a company (callas software) that has commercial software that handles all of these. The tool also has support for PDF/UA, but the verification is only partial.
The reason is subtle but important. All other PDF based ISO standards state that PDF files need to follow certain guidelines, and those guidelines are easy to verify in software. This or that property has to be set, that property can't have this value, this element must have that or that color space...
PDF/UA makes many of such claims as well, but it also makes different claims. Two examples:
For a document to be compliant with PDF/UA, all text in the document must be tagged with the "correct" language.
Similarly, the elements in the document must be tagged with their type (image, paragraph, title, footnote, table) "in a correct way".
The problem is not for software to check that language tags are present or that structure is present. The problem is for the software to verify that the language tags are indeed for the correct language. And that the structure in the document corresponds to what a human would think makes sense.
There are more examples like that in the PDF/UA standard, and they mean that while software can definitely assist in the verification process, it can't conclusively say that the file is correct. The best it can ever say is that it doesn't contradict one of the computer verifiable rules.
I need to implement an authentication procedure between a reader an NFC tag but being my knowledge limited in this area I will appreciated some aid in order to understand few concepts.
Pardon in advance for rewrite the Bible but I could not summarize it more.
There are many tags families ( ICODE, MIFARE, NTAG...) but after doing a research I think NTAG 424 DNA matches my requirements(I need mainly authentication features).
It comes with AES encryption, CMAC protocol and 3-pass-authentication system and here is when I started to need assistance.
AES -> As I am concerned this is a block cipher to encrypt plain texts via permutations and mapping. Is a symmetric standard and it does not use the master key, instead session keys are used being them derivations from the master key. (Q01: What I do not know is where this keys are stored in the tag. Keys must be stored on specialized HW but no tag "specs" remark this, apart from MIFARE SAM labels.)
CMAC -> It is an alteration of CBC-MAC to make authentication secure for dynamically sized messages. If data is not confidential then MAC can be used on plain-texts to verify them, but to gain confidentiality and authentication features "Encrypt-than-mac" must be pursuit. Here also session keys are used, but not the same keys used in the encryption step.(Q02: The overall view of CMAC may be a protocol to implement verification along with confidentiality, this is my opinion and could be wrong.)
3-pass-protocol -> ISO/IEC 9798-2 norm where tag and reader are mutually verified. It may also use MAC along with session keys to achieve this task.(Q03: I think this is the upper layer of all the system to verify tags and readers. The "3 pass protocol" relays in MAC to be functional and, if confidentiality features are also needed, then CMAC might be used instead of single MAC. CMAC needs AES to be functional, applying session keys on each step. Please correct me if I am posting savages mistakes)
/*********/
P.S: I am aware that this is a coding related forum but surely I can find here someone with more knowledge than me about cryptography to answer this questions.
P.S.S: I totally do not know where master and session keys are kept in the Tag side. Have they need to be include by a separate HW along with the main NFC circuit ?
(Target)
This is to implement a mutual verification process between tag and reader, using the NTAG 424 DNA TagTamper label. (The target is to avoid 3º parties copies, being authentication the predominant part instead of message confidentiality)
Lack of knowledge of cryptography and trying to understand how AES, CMAC and the mutual authentication are used on this NTAG.
(Extra Info)
NTAG 424 DNA TT: https://www.nxp.com/products/identification-security/rfid/nfc-hf/ntag/ntag-for-tags-labels/ntag-424-dna-424-dna-tagtamper-advanced-security-and-privacy-for-trusted-iot-applications:NTAG424DNA
ISO 9798-2: http://bcc.portal.gov.bd/sites/default/files/files/bcc.portal.gov.bd/page/adeaf3e5_cc55_4222_8767_f26bcaec3f70/ISO_IEC_9798-2.pdf
3-pass-authentication:https://prezi.com/p/rk6rhd03jjo5/3-pass-mutual-authentication/
Keys storage HW:https://www.microchip.com/design-centers/security-ics/cryptoauthentication
The NTAG424 chips are not particularly easy to use, but they offer some nice features which can be used for different security applications. However one important thing to note, is that although it heavily relies on encryption, from an implementation side, that is not the main challenge, because all of the aes encryption, cmac computation and so on is already available as some sort of package or library in most programming languages. Some examples are even given by nxp in their application note. For example in python you will be able to use the AES package from Crypto.Cipher import AES as stated in one of the examples of the application note.
My advice is to simply retrace their personalization example beginning at the initial authentication, and then work your way up to whatever you are trying to achieve. It is also possible to use these examples in order to test the encryption and the building of apdu commands. Most of the work is not hard, but sometimes the NXP documents can be a bit confusing.
One small note, if you are working with python, there is some code available on github which you might be able to reuse.
For iOS, I'm working on a library for DNA communication, NfcDnaKit:
https://github.com/johnnyb/nfc-dna-kit
Very new to cTAKES and looking through the docs, curious about what exactly the UMLS and SNOMEDCT "vocabularies" are. The user installation docs don't really seem to tell and simply applying for the UMLS license and the language around the UMLS Metathesaurus does not really divulge much more about the structure of the data being accessed. Eg. is it some online API service? Is it some files that come with the cTAKES download that can only be unlocked with a valid UMLS password that is checked against an online DB?
Info on what the UMLS Metathesaurus and SNOMEDCT are can be found here (https://www.nlm.nih.gov/research/umls/knowledge_sources/metathesaurus/index.html) and here (https://www.ncbi.nlm.nih.gov/books/NBK9676/, specifically https://www.ncbi.nlm.nih.gov/books/NBK9684/):
The Metathesaurus is a very large, multi-purpose, and multi-lingual [relational?] vocabulary database that contains information about biomedical and health related concepts, their various names, and the relationships among them. Designed for use by system developers...
...The Metathesaurus contains concepts, concept names, and other attributes from more than 100 terminologies, classifications, and thesauri, some in multiple editions.
While I'm not sure how exactly cTAKES implements its use of the UMLS Metathesaurus (anyone who knows could please enlighten), I assume that it is accessing some API for a relational database based on the UMLS credentials you need to add to the example scripts that come with the cTAKES download (see https://cwiki.apache.org/confluence/display/CTAKES/cTAKES+4.0+User+Install+Guide#cTAKES4.0UserInstallGuide-(Recommended)AddUMLSaccessrights).
...You may select from two relational formats: the Rich Release Format (RRF), introduced in 2004, and the Original Release Format (ORF).
(I think) this is what is used to power the UIMA analysis engines used to process text in cTAKES
UIMA is an architecture in which basic building blocks called Analysis Engines (AEs) are composed in order to analyze a document [...] How Annotators represent and share their results is an important part of the UIMA architecture. To enable composition and reuse, UIMA defines a Common Analysis Structure (CAS) precisely for these purposes. The CAS is an object-based container that manages and stores typed objects having properties and values, https://www.ibm.com/developerworks/data/downloads/uima/#How-does-it-work
While there are lot of posts on how to check PDF/A compliance but seemingly there are no posts about testing PDF/UA compliance.
I checked in Acrobat Pro even, we cannot verify PDF/UA compliance through that software.
The only nearest tool which I could find was PAC (PDF accessibility checker).
But I am not sure if that is sufficient for UA compliance.
Is there any tool which you know that can do this job ?
If you run the validation for the "a" variants of PDF/A (PDF/A-1a, PDF/A-2a, etc.) and it passes you'll know if the PDF meets the structural requirements for PDF/UA. However, the machine validators really can't address the semantic requirements...
Complete tagging of "real content" in logical reading order
Tags must correctly represent the document's semantic structures (headings, lists, tables, etc.)
Problematic content is prohibited, including illogical headings, the use of color/contrast to convey information, inaccessible JavaScript, and more
Meaningful graphics must include alternative text descriptions
I want to know the difference between esignature and digital signature? I tried googling it and I got some information about digital signature and how they are authenticated.
But what I am not able to understand is whether the same authentication process is valid for eSignature? If it's different then what is the exact process?
An eSignature refers to the electronic signing process that creates a legally binding agreement, while a digital signature tends to mean the cryptographic signature produced by public/private key signing.
A public/private key digital signature could be one of the signing methods used for eSignature.
The reason a digital signature is not an eSignature is that applying it alone won't create a legally binding agreement, for example, you could apply a digital signature to secure some data for transmission through an untrusted network (in fact this was the original purpose of the public/private key).
By analogy you could think of your handwritten signature equivalent - you can sign your name on a blank piece of paper or a guest book as many times as you like, no legal obligation is being created upon you. It's not only the signing method that creates a signature but the wider context.
I don't think there is a strict answer to the authentication process for an eSignature. It may be better to look at it as a set of principles that need to be established, since this can spawn any number of specific processes. (By 'authentication process' i take it you mean the process to generate a legally binding agreement).
The reason formation of contract is more principle-oriented and not a fixed process is that fundamentally you can form contracts in any way you choose between yourself and another party, so long as it conforms to a number of principles - for instance, that you're authorized to make that agreement in the first place, that there is consensus between you and the other person etc. Although some specific contracts may be regulated to be of a certain form and type.
I agree that the semantics around eSignature are still evolving and ambiguous. The industry is still relatively young and companies attempt to express their offering in different ways in the absence of a strong and developed vocabulary. Finally I would just say that nothing in this answer should be construed as legal advice. I hope this goes some way to answering your question.
An electronic signature is a legal concept that is defined in the eIDAS Regulation by the following:
‘electronic signature’ means data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign; (eIDAS Article 3.10)
This implies that an electronic signature may be represented by any type of data associated with a person and a content in electronic form. For example, it may be a text with a person's name in the end of an email, or a visual stamp within an electronic document.
A digital signature, on the other hand, refers to a mathematical and cryptographic concept that is widely used to provide concrete and practical instances of electronic signatures. The definition given by ETSI TR 119 100 is that of
Digital signature is data appended to, or a cryptographic transformation of a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery e.g. by the recipient.
A digital signature provides a proof of the content integrity and the signature creator.
These two concepts should be distinguished, as all electronic signatures are not necessarily digital signatures.
For more information about electronic signatures, you will need to look into eIDAS Regulation, that distinguish three types of electronic signatures:
1. 'Simple' electronic signatures
See definition for "electronic signature" above.
2. Advanced electronic signatures (AdES)
An advanced electronic signature is an electronic signature which is additionally:
uniquely linked to and capable of identifying the signatory;
created in a way that allows the signatory to retain control;
linked to the document in a way that any subsequent change of the data is detectable.
The most commonly used technology able to provide these requirements relies on the use of a public-key infrastructure (PKI), which involves the use of certificates and cryptographic keys.
Advanced signature is a digital signature.
3. Qualified electronic signatures (QES)
A qualified electronic signature is an advanced electronic signature which is additionally:
created by a qualified signature creation device (QSCD); and
is based on a qualified certificate for electronic signatures.
For more information about electronic signatures please see eSignature FAQ from the European Commission website.