I have to deal with certificates issued by the Swiss post office on USB tokens. There deliver two certificates on the same token. In their intended usage fields, one has "non repudiation" and the other "digital signature".
Now, I can't understand what the practical difference between the two are: I've always seen both in the same certificate, never two certs for the same identity each with one of the roles. In fact, I can't imagine a scenario where non-repudiation and digital signature aren't the same, for all practical matter, the same thing.
Could anyone explain to me what the difference is, please ? And if you had a suggestion about in what situation one should be picked over the other, that would help as well.s
I realise this question is a bit old, but I think I can shed some much-needed light on the question.
The non-repudiation value in the keyUsage attribute relates to the whole certificate, not any purpose in particular. The presence of the non-repudiation flag indicates that the private key has sufficient protections in place that the entity named in the certificate cannot later repudiate—deny—actions they take with the certificate. The presence of the flag doesn't prevent repudiation, rather it indicates that repudiation isn't likely to survive reasonable scrutiny.
So in this specific case, the CA is giving the user the option of a certificate that does or does not include the non-repudiation element. If you want to assert to those verifying the signature that you can't easily deny it was you who signed it (the USB token is the key enabler here), use the non-repudiation certificate. Otherwise, use the certificate marked for digital signatures. (Depending on the other attributes in the certificate, you may or may not be able to sign documents with either or both certificates.)
See Wikipedia: http://en.wikipedia.org/wiki/Non-repudiation
See also the relevant RFC: http://www.faqs.org/rfcs/rfc3280.html (section 4.2.1.3)
I talked to the guy who implemented it and, apparently, they intended the "non-repudiation" cert for /really/ signing documents and the "digital signature" one to be used for authentication.
"digital signature" means that you can guarantee the origin of the document or the id of the user; this is AUTHENTICATION.
"non repudiation" means that the document is approved, this is content commitment also called ELECTRONIC SIGNATURE (not digital signature).
Hope this helps because one's always asked this question even in 2013.
Interesting question, and your thoughts match my own.
I've found a reference at IBM here about key usage, but I still can't really get my head around the distinction.
The best that I can phrase my understanding having read the article is that a non-repudiation usage means "I really meant to sign this, and I really understand the implications of signing this."
Sorry this isn't a complete answer, but I hope it helps.
EDIT 4th April 2014
I just got given more points again. The answer from #Calrion is much better, so send any +1s that way.
"digital signature" should be used for authentication (it was you, who signed this), while "non repudiation" means that you know what you was signed.
If you use your private certificate for authentication (against some server) the authentication works following way: During establishing the connection your browser (or other SW) signed some random data provided by server to prove that it was you on the other side. But the key point is that you have no control which data you are signing. Thus the server can you send instead of random data send "I, Petr Novonty, give all my money to James Clark."
To avoid this, key used for signing some documents should have "non repudiation" and not "digital signature" bits set.
This page gives somewhat clear descriptions of all the key usages:
https://www.ibm.com/support/knowledgecenter/en/SSKTMJ_9.0.1/admin/conf_keyusageextensionsandextendedkeyusage_r.html.
Keep in mind, that X.509 renamed the nonRepudiation bit in contentCommitment. This seems to be better than a description via "non". So this remark supports the answer given by Franck Leroy.
Note that they are simple bits, their names give only indications for the key usage. Some explanations of these bits are given in RFC 5280. But how to interpret distinctions between these two is finally left to the certificate issuer. RFC 5280 says on this "Further distinctions between the digitalSignature and nonRepudiation bits may be provided in specific certificate policies."
https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3
Related
I am trying to implement signed code for some PS scripts, and I have a question about trusting certificates.
I know the "right" way to address this is for IT to use Group Policy to trust the certificate office wide. But many of my customers just don't really have that option. My thought is to provide instructions on using CertUtil.exe to do the job, but I wanted to be 100% sure that adding to trustedpublisher this way still results in the certificate being validated by the issuing authority at startup or login, so a revoked certificate in trusted publishers would in fact not be trusted, correct?
Also, give that the tool to be run is a management tool, my initial thought is to use the tool to drive CertUtil.exe. Basically the first time you use it it adds its own certificate, so you get some user interaction required on first use only. But the idea of code creating a trust for itself seems potentially sketchy, and would raise a little flag for me if I was on the other side wearing my IT hat. So, from a PS distribution model standpoint, is setting up one's own certificate considered appropriate, or verboten, or something of a gray area?
If I recall correctly revocation is almost immediate, with a possible short time lag due to pre-fetching. you can find more info on how exactly revocation is handled here - https://technet.microsoft.com/en-us/library/ee619754(v=ws.10).aspx
As far as adding your own cert I don't see an issue with it but if they require code signing for scripts it won't be able to do it's initial launch, personally I'd send the certutil stuff as a separate script (potentially a batch file) and keep the code you are actually sending over all signed.
I've been included in an analysis project or "cleaning up" of information which includes fields from certificates. I don't know how to access the actual certificates. I'd like to learn as much as I can about how/what can be verified in relation to a certificate. (I'm not doing security work, I just need to read the information.)
I have several spreadsheets with information including certificate data, all different sources with different fields. I'm trying to consolidate this information into a single table with as much verified as possible. Most records have Control Name, Serial Number, URL, etc., but based on the inconsistencies throughout other fields I think wrong or incomplete data has been added.
For instance, I'd like to verify that the expiration date on a spreadsheet is what is actually on the certificate. It also looks like one of the spreadsheets converted long serial numbers into a numeric data type, truncating(all 0's) the last half of the SN. Is there a way to look up all of a CN's certificates issued by a CA?
I'm very new to this, any tips would be appreciated.
Thank you
There is no general, public way I know of.
However, you might be able to get in touch with some CAs and do a research cooperation, but I doubt it. Handing out certificates to somebody else could be a privacy concern. And there's no chance you'll get certificates from all the CAs out there.
What you can do is obtain the certificates when they are used for publicly available services. For example if a certificate is issued to mail.example.com you could try to establish a TLS session to the host. You may have to try different ports, and maybe you are lucky and the host presents the certificate you are looking for.
My company develops an ERP for hospitals and because of some legislation changes throughout this weekend I've been reading a lot on digital signature because I need to solve the following scenario:
Each doctor will receive from the ministry of health a certificate (so there's no escape from it... government said so...) and all of his reports sent/stored in digital format must be signed with this certificate.
The certificates will be valid for one year. Each year upon renewing of the medical license, the certificate will be renewed.
Our main concern here is guaranteeing the source of the document (the sender is who he claims to be) but we must also make "impossible" (or at least infeasible) to change the content of the document (or at least that if it changes, we have to be able to tell that a modification occurred) and to "extracted and replicated" the signature...
My question is: how do I deal with this whole thing? What should I do?
PS: In your answer pls consider that:
The documents will persist far beyond the certificate lifetime.
The certificate might have been revoked. Documents signed before the revoke must still be valid
How a 3rd party would verify the integrity of the information (document + certification)
Is there not a security principle which states that information signed with a expired certificate is invalid or something?
I'm really new to this area and I might be asking the wrong question...
In brief, the document must be signed using CAdES, PAdES or XAdES (depending on data format) standard, where timestamping is applied and other measures are taken. These standards were designed specifically for tasks similar to yours so they address your concerns. I recommend that you read some articles about those formats. Unfortunately I don't have a link to share with you right now, but you can find a lot based on those abbreviations.
CAdES is based on PKCS#7/CMS (certificate-based signing of generic data with wrapping signatures) .
PAdES is an extension of PDF signing and is used specifically for PDF documents.
XAdES is similar to CAdES and can be used to sign XML documents and (more rarely) binary data.
[Disclosure: I work for CoSign by ARX.]
Your situation is common. You're raising a number of questions. My answers:
all of his reports sent/stored in digital format must be signed with this certificate.
You can digitally sign anything (any bundle of bits). The real issue is how can the recipient or auditor easily verify that the document:
was not modified since it was signed (integrity)
was signed by the right person (identity)
was signed with the right intent (signer's statement)
Machine readable data, eg form data, intermediate data, etc.
Signing: For info that is designed to be later machine-read (eg a form submission), store the info in XML and sign it using the XML Signing Standard: XAdES The CoSign Signature API (SAPI) directly supports signing XML docs.
Verifying There are many on-line XML digital signature verification services, Google for them. The SAPI api also supports verifying XML docs.
Human readable documents
Signing: For a "final" document that will be read by humans (but is stored digitally, can be included in searches, etc), PDF documents are the way to go. The PDF format supports digital signatures very well. There are many ways to add digital signatures to PDF documents. For developers, the CoSign Signature Web Agent is a web service (HTTPS + XML parameter document) that handles all the UI issues of signing.
Verifying: The most common way to verify the digital signatures of a pdf is to use the free Adobe Reader. (Not the expensive Adobe Acrobat.) Adobe Reader knows how to check the validity of the digital signatures and then tells the reader/signer/auditor that the signature is valid, the document was not changed since signed, etc.
Your other questions:
The documents will persist far beyond the certificate lifetime.
Yes, that is fine. Just like a "wet signature," once you've validly digitally signed a document, that document remains signed by you. -- Even if your signing certificate later expires. As part of the verification process, the date of signing is compared with the valid dates on the certificate.
The certificate might have been revoked. Documents signed before the revoke must still be valid
Yes, that is how standard digital signatures work. Even if a certificate is revoked, documents signed while the certificate was valid will remain signed. Because date/timestamps play such an important part of the validation process, there are 3rd party timestamping services available. But they are not used for most digital signatures. Instead, create explicit management procedures to make sure that the time server is properly setup with NTP to a good source and that the system is regularly checked and verified.
CoSign signs using a tamper-proof hw device. Its clock is synched using NTP.
How a 3rd party would verify the integrity of the information (document + certification)
As I discuss above, the whole verification question is important. That's why I recommend using XML or PDF as your document types. You could, for example, digitally sign your own system's internal data structure used to represent information. In this case the digital signature would be carried in a separate data structure. This is the "external signature" scenario. It all works fine, except that an auditor would need to either build his own sw to validate or trust that your sw is doing the validation properly. A better choice is to use a format that directly supports digital signatures and which can be easily verified.
Is there not a security principle which states that information signed with a expired certificate is invalid or something?
A proper digital signature system won't allow an expired certificate to be used to sign anything. Once something is signed, using a certificate that was valid at time of signing, it stays signed unless the document is subsequently changed.
I'm really new to this area and I might be asking the wrong question...
Other questions to ask: how do you add the signer's graphical signature to the document (XML or PDF)--people expect to see it. And how do you manage/administer the certificates? Server based signing is a good solution for this. Remember that certificates should not be stored in sw for any production systems. Instead, a Secure Signature Creation Device (something hw based) must be used.
You will also need to read the Baseline Profiles where there is a profile for long-term signatures.
There is a profile for each of the formats already mentioned by Eugene.
For example, if your document is PDF, you may use PAdES signatures and the LTA-Level specified in "PAdES Baseline Profile" document.
All of these documents are ETSI standards you can search for at: http://pda.etsi.org/pda/queryform.asp
I wonder if it is possible to have an easy authentication method that is restful, fast and provides a litte security.
SSL is not an option, because I can't rely on a valid SSL Certificate on the server of clients. Also HMAC is not really possible because the body of the request should be signed, when used properly, but in my case that body could be a large file. Further should the authentication be possible with JavaScript/AJAX.
I thought about something really simple. What's the problem with that one:
HEADER: X-Authentication: timestamp:username:sha256(timestamp:password)
The server knows the users password and could check the hash, the timestamp is used to only allow request that took place e.g. 10 seconds before. The replay window would be extremly small, and there are no sessions on the serverside.
If the hash is cracked the attacker knows the password and has unlimited access.
Alternative would be to use
HEADER: X-Authentication: timestamp:username:HMAC(password, 'timestamp+request-method+verb')
What's the way to go? I'm not a security pro, maybe storing the session on the server would be better (but not RESTful)?
I built a random hash algorithm that does what you need, it's called jAuthenticate.
You can download it from: https://github.com/thomasoeser/jAuthenticate
You can see how it works here: http://furiousgryphon.com/jauthenticatedemo.html
The reason it's a strong algorithm (in my opinion) is that I'm using a random number to influence the hash but I'm sending an obfuscated number with the hash.
Each hash is single use only.
Have a look, it's free open source (MIT).
HTTP authentication is extensible so you can invent your own mechanism (obviously at your own risk!). See https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p7-auth-20 for details.
Don't bother inventing your own new X- header. Using the existing Authorization header with your scheme is a better option.
e.g.
Authorization: kruemel-auth timestamp:HMAC(password, 'timestamp+request-method+verb')
Ideally new schemes will be registered with IANA along with a specification. A registry is being setup to track auth schemes that have been developed. See http://tools.ietf.org/id/draft-ietf-httpbis-authscheme-registrations-03.html
I'm designing an iPhone app that communicates with a server over HTTP.
I only want the app, not arbitrary HTTP clients, to be able to POST to certain URL's on the server. So I'll set up the server to only validate POSTs that include a secret token, and set up the app to include that secret token. All requests that include this token will be sent only over an HTTPS connection, so that it cannot be sniffed.
Do you see any flaws with this reasoning? For example, would it be possible to read the token out of the compiled app using "strings", a hex editor, etc? I wouldn't be storing this token in a .plist or other plain-text format, of course.
Suggestions for an alternate design are welcome.
In general, assuming that a determined attacker can't discover a key that is embedded in application on a device under his physical control (and, probably, that he owns anyway) is unwarranted. Look at all of the broken DRM schemes that relied on this assumption.
What really matters is who's trying to get the key, and what their incentive is. Sell a product aimed at a demographic that isn't eager to steal. Price your product so that it's cheaper to buy it than it is to discover the key. Provide good service to your customers. These are all marketing and legal issues, rather than technological.
If you do embed a key, use a method that requires each client to discover the key themselves, like requiring a different key for each client. You don't want a situation where one attacker can discover the key and publish it, granting everyone access.
The iPhone does provide the "KeyChain" API, which can help the application hide secrets from the device owner, for better or worse. But, anything is breakable.
The way I understand it, yes, the key could be retrieved from the app one way or another. It's almost impossible to hide something in the Objective-C runtime due to the very nature of it. To the best of my knowledge, only Omni have managed it with their serial numbers, apparently by keeping the critical code in C (Cocoa Insecurity).
It might be a lot of work (I've no idea how complex it is to implement), but you might want to consider using the push notifications to send an authentication key with a validity of one hour to the program every hour. This would largely offload the problem of verifying that it's your app to Apple.
I suggest to add some checksum (md5/sha1) based on the sent data and a secret key that your app and the server knows.
Applications can be disassembled so that they could find your key.
More information is needed to determine whether the approach is sound. It may be sound for one asset being protected and unsound for another, all based on the value of the asset and the cost if the asset is revealed.
Several earlier posters have alluded to the fact that anything on the device can be revealed by a determined attacker. So, the best you can do is determine valuable the asset is and put enough hurdles in the way of the attacker that the cost of the attack exceeds the value of the asset.
One could add to your scheme client-side certificates for the SSL. One could bury that cert and the key for the token deep in some obfuscated code. One could probably craft a scheme using public/private key cryptography to further obscure the token. One could implement a challenge/response protocol that has a time boxed response time wherein the server challenges the app and the app has X milliseconds to respond before it's disconnected.
The number and complexity of the hurdles all depend on the value of the asset.
Jack
You should look into the Entrust Technologies (www.entrust.com) product line for two-factor authentication tied to all sorts of specifics (e.g., device, IMEI, application serial number, user ID, etc.)