I do the following steps for signing a single data with a smart card with the ISO7816 standard.
Select MF
Select DF
Verify Pin
Manage security environment
Compute digital signature
If I want to sign multiple data then I follow these steps :
Select MF
Select DF
Verify Pin
Manage security environment
Compute digital signature 1
Verify Pin
Manage security environment
Compute digital signature 2
Verify Pin
Manage security environment
Compute digital signature 3
Do i have to do VerifyPin and manage security environment steps everytime?
If I try these steps:
Select MF
Select DF
Verify Pin
Manage security environment
Compute digital signature 1
Compute digital signature 2
I'm getting 69 82 (Security condition not satisfied.) in step 6.
What you are describing is the concept typically called bulk signature. It is supported by some cards, but most likely this requires a modification of the personalization sequence used to setup the card before issuance or a different ordering option. The more secure standard behavior (as you observe in the example) is, that the acquired access right is exhausted by the signing process.
There are serious legal obstacles, since digital signatures are considered as a willful act, so imply that you were aware of what you signed and intended to do so by entering the PIN. Under conditions asking for a bulk signature, typically considerable organizational security provisions have to be supplemented to the environment, so a doctor, who intends to sign electronic prescriptions, has to make plausible, that the card reader is under his/her continuous supervision.
There are more restricted forms of bulk signature, where the PIN has not to be entered every time, but e.g. every 10th time, since the unlimited signature capability is too dangerous.
Just to clarify this: if a card is hardwired for single signature per PIN entry, there is nothing an application can do to achieve bulk signature instead.
Summarized: While a PIN entry proves the presence of the legitimate card holder, this is insufficent for the willful act aspect of digital signatures.
Related
I have an HLR security question in terms of risk assessment, which is broadly beyond my areas of expertise.
If an HLR was potentially hacked, would that create a risk of SIM card cloning (among other risks obviously)?
In other words, does accessing the HLR command line reveal information about the SIM cards aside from the IMSI, MSISDN, etc. (namely the Ki key) that would enable hackers to produce cloned SIM cards for select subscribers? My understanding is that having the IMSI and Ki is sufficient for SIM card cloning.
If that is indeed a risk, would changing the transport keys of all SIM cards in the HLR(s) solve the problem by preventing a cloned SIM card from attaching to the network? Or is that irrelevant?
My understanding is that change the transport keys won't matter for existing SIM cards but it would protect new SIM cards to not have the Ki key revealed in the network. But I just want to verify.
Thanks!
The authentication process is actually quite complex and also differs between mobile standards versions (2G, 3G etc although these are not precise terms). In general, the HLR does not keep or transmit the secret key associated with a SIM. In UMTS there is a AUC component which does keep the secret info.
It's worth remembering that it is the SIM that is verifying itself to the network - at a 10,000 meter level it does this by applying some crypto algorithms to a random value the network sends it and returning a result. The Network also has a copy of the expected result (for that Random value) and if they match it concludes the SIM is valid.
Ultimately, any secret keys that allow the network calculate the expected result must be stored somewhere and if that store is compromised then there is definitely a problem. However, accessing a HLR should not provide access to these keys, although it may enable some attacks.
There is a really nice overview here (at the time of writing) which helps show the flow: https://steemit.com/mobilenetworks/#irelandscape/introduction-to-mobile-networks-3g-umts-authentication
Yes it definitely should happen (statistically and given the overall level of security negligence). There should be a reason we never hear about that. No, transport keys are irrelevant once HLR is compromised.
I have a (university) project where I basically write and read text out of an NFC tag with Android devices in order to store one's balance in the card (which can be used on the cafeteria, for example).
Right now, I'm using NTAG213 doing the below code:
ndef.connect();
NdefRecord mimeRecord = NdefRecord.createMime("text/plain", messageEncrypted.getBytes(Charset.forName("US-ASCII")));
ndef.writeNdefMessage(new NdefMessage(mimeRecord));
ndef.close();
As you can notice, I'm using application level encryption to encrypt the message (messageEncrypted) before writing it to the tag (AES-256 encrypt with 'com.scottyab:aescrypt:0.0.1' library - with a very big password key that uses also the tag UID as part of it).
So far so good - only I can understand the data on the tag.
On my research, I've found that when it comes to security Ultralight C > NTAG213.
Question 1) When using application level encryption, why (is it?) is MIFARE Ultralight C safer then NTAG213?
Question 2) I'm pretty sure I can guarantee security using AES encryption, but I don't want people (besides me) messing with the stored data (formatting tag or writing info there). I see that the only way of preventing that (please, correct me if I'm wrong) is to set a password for the tag. However, both NTAG213 and Ultralight C have only an 32-bit password. Is it good enough? Is there another way of preventing someone (besides me) writing data?
Question 3) Which other security measures can I use on such tags to enforce security (tag and application layer)?
Question 4) When you compare tag security (MIFARE DESFire > Ultralight > NTAG213 > MIFARE Classic), what is really being compared? The ease of one cracking the (native tag's) encryption or the ease of one store (anything) on the tag without permission?
Question 5) I see a bunch of other techs (MIFARE DESFire, ICODE SLIX, Infineon Cipurse) that are more secure, which makes me wonder if the tech I'm using (NTAG213 or Ultralight C) is good enough for storing someones balance. Would you (and that's a personal opinion) say that NTAG213 with application level encryption and 32-bit password good enough for this type of application? And how long would it take someone to actually break its security?
When using application level encryption, why is Ultralight C safer then NTAG213? Is that even true?
First of all, "safer" depends on what your actual protection goals are. Since you want to store a balance (cash money!) on the card, you would probably want to (at least) protect towards the following goals:
Users must not be able to print their own money by setting an arbitrary balance on their card.
Users must not be able to duplicate their card and, consequently, their money balance.
Users must not be able to print their own money by restoring (roll-back) their card to a previous balance after payment.
Users must not be able to print their own money by replaying a top-up procedure.
Users must not be able to evade payment by tearing their card during a payment transaction.
Users must not be able to generate an arbitrary (and potentially higher) balance on their card by tearing their card during a top-up procedure.
In addition, you might not want to trust operators (the persons accepting payments and performing top-up) as well. In a system where one group of operators performs only top-up and the other performs only payment transactions, the latter group should probably not be allowed to ever "create" money. Particularly, you have to make yourself very clear about whether you fully trust the (Android) devices that you use in the field to perform these operations and whether you trust operators (e.g. that they don't perform any attacks against these devices).
Moreover, there might be privacy aspects that you need to consider (e.g. if the balance is freely readable, if users are identifiable, etc.)
So let's look into what you "application level encryption" adds in terms of security:
Since users do not know the encryption key, they are probably not able to generate an arbitrary balance on their card. However, this heavily depends on the format of your balance (in unencrypted form). Users can make arbitrary modifications to the cipher text with result in "random" modifications of the plain text. Consequently, users may be able to modify the balance value despite encryption. Digital signature/message authentication codes are they path that you would probably want to take to overcome this.
Since the encryption key (assuming encryption would be sufficient, which it probably is not) depends on the UID of the tag, you may be safe against cloning of cards (+ balance). However, be aware that the UID is just a freely readable identifier. It is by no means authenticated itself and may be clonable as well. See Serials on NFC Tags - truly unique? cloneable?.
The encrypted value does not protect you from users restoring their balance to a previously recorded value after payment. This type of vulnerability has been found before (particularly in MIFARE Ultralight based systems), see, for instance, Benninger, C., Sobell, M. (2012): NFC for free rides and rooms (on your phone). In: Presentation at EUSecWest 2012.
Since you write the complete value during a top-up procedure (i.e. there is no specific "increment balance" command), you are probably safe against users replaying a top-up (except for the roll-back aspect of this).
Effects of tearing are probably rather limited if your system only allows for attended payment/top-up.
So let's see what additional features NTAG213 would have that you could use to secure your system:
UID is unique on genuine tags. This does not help much, see Serials on NFC Tags - truly unique? cloneable?.
Originality signature: same as above, the originality signature is also just a static, freely readable value. Consequently, it's just as well susceptible to cloning.
The one-way counter might be a tool to help you in protecting against roll-back (by including the counter value into the signature). This still would not prevent cloning onto a tag platform that allows to generate arbitrary counter values. Moreover, the counter is not easily controllable and will change its value if the user tries to read the tag. Consequently, it's questionable if an implementation based on that value would be reliable.
Unlike MIFARE Ultralight, NTAG213 does not have a usable one-time programmable area (since that's already used by the capability container). Consequently, you can't implement a one-time deductible balance based on that.
The password protection feature could help you in authenticating tags (by performing password verification) and in protecting the value stored on the tag (by making the value only readable/writable after password verification). However, the password is transmitted in clear text (may be subject to sniffing, particularly in (but not limited to) unattended scenarios) and there is no cryptographic binding between the password and the actual read/write.
MIFARE Ultralight C would add the following:
The OTP bytes can be used. If it's an option to make the tags one-time usable (i.e. they start with a specific balance that can only be deducted from and not topped-up), then using the OTP bytes to represent the balance would be an option. Note that there's still lots of things that you could do wrong with that, e.g. Beccaro, M., Collura, M. (2013): OTP circumventing in MIFARE ULTRALIGHT: Who says free rides?. In: Presentation at DEFCON 21
The authentication is much improved. The 3DES authentication scheme seems to be sufficiently secure to prevent sniffing the key. However, read/write commands are also not cryptographically bound to the authentication step. Consequently, an attacker might be able to let a genuine payment terminal + genuine tag perform authentication, but redirect read/write to somewhere else. This might (particularly) be a problem in an unattended scenario.
I'm pretty sure I can guarantee security using AES encryption.
See above. This is probably not true.
I don't want people messing with the stored data. I see that the only way of preventing that is to set a password for the tag.
A password/authentication key may help, but be aware of the limitations due to authentication being decoupled from read/write on these tag platforms.
Both NTAG213 and Ultralight C have only a 32-bit password.
This is not true. NTAG213 has a 32-bit password. MIFARE Ultralight C uses a more sophisticated mutual 2K-3DES authentication mechanism with a 112-bit key.
When you compare tag security, what is really being compared?
Authentication mechanisms (algorithms, key sizes)
Communication security (e.g. is the communication itself encrypted/authenticated using a session key derived from the authentication step?)
Access control (e.g. are there separate keys for top-up and payment?)
Are there dedicated mechanisms for balance management (e.g. value fields, dedicated increment/decrement operations)? And, consequently, are ther mechanisms to protect agains tearing attacks?
And probably more ...
I see a bunch of other techs that are more secure, which makes me wonder if the tech I'm using is good enough for storing someones balance.
You specific system is flawed in many ways. In my opinion MIFARE Ultralight/NTAG203/NTAG21x are definitely not a good choice for a an offline system storing cash money on the cards.
MIFARE Ultralight C may be suitable with some precautions. I would definitely refrain from using that in unattended scenarios, and I would probably use an online system tracking the balance and monitoring for inconsistencies.
Anything that uses symmetric cryptography and storing the cryptographic keys in a terminal would certainly require precautions against malicious operators. It's probably fairly easy for an operator (with some knowledge) to extract keys from an app and generate their own money.
I guess your question is too broad and not for all subquestions this section of SO is the most appropriate one.
By focusing on cryptographic strength you miss something: if the low level security of the token can be easily attacked, nobody needs to crack your key.
A simple dump and later restore (after some payments) corresponds to printing money
If the token contains the money directly (instead of only identifying the wallet, which is stored on a background system), you need a far more secure system to avoid financial damage. This involves dynamically encrypted communication but continues with substantial further topics.
A multiple factor authentication system (software or others) requires an entity to produce data in support of multiple factors of authentication. Generally these factors are:
Something you have e.g. debit card.
Something you know e.g. PIN
Something you are e.g. biometrics
These factors can uniquely establish the authenticity of an entity to a system. However the system is blind to the entity itself that produces the data in support of the factors. For example, cards can be forged, phone receiving an OTP can be stolen, biometrics can be stolen (finger and iris vein seem to be resistant though).
Therefore, would it be true to say that an authentication system can only infer that an entity is what it is based on data provided?
I am working on a Java Card application where our requirement is to keep some static data and balance in the card.
For security I was thinking to make 2 object of OwnerPIN. One object is for terminal authentication (i.e. the terminal needs to send 8 bytes of data to authenticate itself) and the other object is for user authentication (i.e. the user needs to enter a 4 digit PIN to authenticate theirself)
Only if both authentications are successful, we can read the data or update the balance.
Or is there any other advice on how to implement security on card to avoid theft?
Also is there any guideline for choosing proprietary class and instruction bytes during applet development?
For user authentication, the OwnerPIN is certainly one good way to go (there are alternatives ofcourse, but OwnerPIN provides security features (e.g. tearing protection) that you would otherwise have to implement manually).
For terminal authentication, nothing should prevent you from using an approach based on an instance of the OwnerPIN. However, depending on your security requirements, you might want to choose some form of mutual authentication instead of a simple PIN code. If the terminal simply sends a PIN code (especially if it does that in plain text), an attacker could simply intercept that PIN code (while sent to a card) and then use that discovered PIN code to create their own (malicious) terminal.
With regard to class and instruction byte (and especially with regard to standard operations like PIN code verification) I would suggest that you stick to standards. ISO/IEC 7816-4 defines many instructions for such standard operations.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
What constitutes a "legal" digital signature for a web form (not a document)?
OPTION 1: I worked on a project where a doctor makes notes on the health of a patient. When the web form is submitted a PDF is generated and digitally signed with a digital .CER certificate and the PDF is saved to the file system. Each doctor had their own .CER file and password which was a real PITA to maintain and the overhead of generating, storing, and backing up PDF's is quite high.
There are also third-party solutions like CoSign which allow the user to authenticate to CoSign as the form submits and, if properly authenticated, somehow digitally signs that form. I believe all of these solutions require an export to various types of documents and then storage of the document and require the end signer to have an account with CoSign. That isn't going to work...
All of these signatures require the data to be stored in a document which is not ideal for many projects.
OPTION 2: I went to the Microsoft store at the Mall of America and purchased a new Surface (to be later returned :/ ) and when checking out they gave me a tablet (ironically it wasn't a Surface) and a pen and I jotted down my signature. Another example is the Square app which also requires the user to jot down their signature on a touchscreen of some sort. I would assume the signature is stored as an image somewhere in a database but does that constitute a "legal" document?
I've worked at a small medical device company which had their doctors evaluate tests on the web and digitally "sign" their evaluation, but all that did was upload an image of their signature saved in the database.
OPTION 3: Yet another way I've seen this done is when filling out my FAFSA for college tuition aid back in the day. They'd ask you to review the terms, yada yada, and then at the bottom I had to type in my full legal name "as it appears above" and the submit the form. What are they doing behind the curtains??
The project I'm working on is a simple one-page contract for a construction company which explains all of the services to be rendered and requires a signature and date. The electronic version of this form would collect all of the required data in a web form and save it to a data store.
My initial reaction was to provide a <canvas> based HTML5 element that can be signed on an iPad or something. Does the data need to be exported to a document and then signed using a digital signature or can the data be legal and "signed" in the data store?
You're asking several questions, only one of which is the legality question.
Disclosure up front: I work for CoSign.
First question:
Signing a web form digitally vs signing a document (PDF, etc)
Yes, this is a common application for digital signatures. CoSign supports it. The usual technique is to first express the web form as an XML file. Then digitally sign the XML file. CoSign's SAPI api directly supports digitally signing XML files according to the W3 standard. Learn more from the SAPI programmers guide. Available from the CoSign Developers site.
Verifying the digitally signed XML file You need the ability to cryptographically verify the digitally signed XML file. You can use CoSign for this or there are many other apps which will also verify the XML files. Google for "verify xml digital signature" to see a long list. Independent verification of the digital signature's identity, intent and the document's integrity are the key advantages of using standard digital signatures.
Second question:
Any way around the high costs of personal copies of digital certs for digital signing?
Issuing, tracking, maintaining, replacing and retiring personal digital certs has a very high cost, as you've discovered. This is a common (and large) downside to digital signatures using hw certs issued to the individual signers (smart cards, usb tokens, etc). The way around the problem is to centrally store the certs as CoSign and some others do. CoSign automatically synchronizes with Active Directory / LDAP etc to get rid of the support and maintenance costs of the individual hw certs.
Third question:
Do outside signers need their own account on the CoSign box? That wouldn't work.
In the case of outside signers (someone outside of the organization, such as a customer/client/patient who only signs once in a great while), the signing account can be created programmatically, the XML doc signed and then the account is deleted. This is not an uncommon case. The CoSign SAPI api supports account creation/maintenance/deletion for this purpose.
Fourth question:
Is it true that "All of these signatures require the data to be stored in a document which is not ideal for many projects?"
No. You can digitally sign XML docs as I explain above. Signing XML docs created from web forms is also done by Microsoft's InfoPath form system, by the IBM Forms system and by others. It is a common application for digital signatures.
Fifth question:
What are Square and other web form signing apps doing?"
In many cases they are doing ""Electronic signatures" not "Digital signatures."
Briefly, an electronic signature is a graphic representation of a person's signature. That's all that's in the document. So the document by itself has no assurance of integrity or non-reputability. Ie, someone can change the document (eg by strategically adding the word "not") and the signature would still look the same.
To add strength to the inherently weak electronic signatures, the various electronic signature services will store the document on their servers, thus providing their corporate assurance of the document's integrity etc. Your option 3 may be in this category. Square, your option 2 may also be an electronic signature. In their case, Square itself is providing the assurance that nothing was changed after signing.
Electronic signatures are generally legal in the US but you should consult a lawyer for details. It is also the case that many organizations won't accept electronic signatures due to their reliance on a third party for verification (the vendor). Electronically signed documents can't be independently verified--you need to rely on the vendor. For example, drug companies cannot submit their paperwork to the FDA with electronic signatures, digital signatures are required. Outside of the US, electronic signatures are often not acceptable again due to the inherent weakness of the technology.
Digital Signatures A document or XML file, or anything else can be digitally signed. The digital signature guarantees, through cryptography techniques, that the document was not altered (integrity), signature is non-reputable (signer identification) and the signer's statement of intent at the time of signing. Digitally signed files can be verified by anyone using verification software or apps available from many places. Digital signatures adhere to open standards, electronic signatures do not.
What constitutes a "legal" digital signature for a web form (not a document)?
There's the matter of existing laws and practices, and there's the matter of what they should have been if the law is written by someone not ignorant of the nature of electronic signature, digital signature, and digital data.
In my opinion, electronic signature (an image of a hand-drawn signature) should never be considered legally binding, it is trivial to forge an electronically signed data, or to create a forged data that contains the image of the signature. They can and are often used in low security situation, however they are worth nothing to assert the authenticity or integrity of data. They can be somewhat secure in a very limited situation, such as when there is a trusted, tamper-proof device to collect the hand drawn signature like EFTPOS or trusted tablets, the consumer's and (usually) the merchant's tablets should not be considered trusted device.
Digital signature, on the other hand, uses cryptographic techniques to embed a signature that can be automatically verified to assert the authenticity of the document/data. It's a very strong guarantee as long as the security of the private key is kept private and no flaws are discovered with the signature algorithm. In my opinion, this is the only form of electronic signature that should be considered legally binding in every situations, assuming all parties understands digital signature.
It is possible to have a trusted third party, acting as a notary, that asserts the authenticity of a document or web form submission. The security of this system depends on the reputation of the notary, it can be legally binding when done by a trusted notary using a proper trustworthy protocol. Some electronic notary employs some form of digital signature, so their assertion adds an extra layer of guarantee on top of those provided by digital signature alone.
Many jurisdictions allow weaker forms of electronic signature for certain kind transactions. Check your local laws, consult a lawyer that is well versed in electronic transactions when in doubt about using weaker form of signature. Use digital signature properly to remove any shred of doubts.
Any finite length binary stream can be signed, it didn't have to be in a document. However, to have an embedded signature as opposed to external signature, the data contained have to have support for containing the signature.