I have Mifare DESFire EV1 with 4Kb of memory. I have created an application with AID "000001". I want to authenticate with key number 1. However, I get "no such key" error code.
So probably I don't know the key inside the card, right? So how can I find out the keys? Should I contact the vendor?
"No such key" means that the key number specified is invalid.
DESFire keys are numbered from zero. Are you sure you created the application with the correct number of keys (i.e. at least two)?
To authenticate with the application master key, use key number 0.
The initial key value is defined by the card settings. The default value is written in the manual.
Related
I am looking to use the data that comes with Cognito as secondary key to connect to other database.Potentially, I could use username or email. However, according to the project requirement, there will be lots of concerns of using sensitive data as primary key for other database. I am looking for an alternative way to set the unique key. Wonder whether userSub can be used as unique key for each users? Or there's any other values that I can use?
When a user is created in Cognito user pools, Cognito generates a sub for each user which is unique throughout the user pool. As such, you can use the sub field as a unique identifier for your users.
Though now considering that you are using usernames for your user, the username needs to be unique and so you can use the username as well instead of the sub.
If the user pool is configured to use email as username - in this case the email needs to be unique for all the users, meaning that there can not be any duplicated email id.
Same goes for phone number if a phone number is configured to be used as username.
So, in the end it is your choice is you want to use sub as a unique identifier in your key or the username.
Im my opinion I would not use an email address as a key.
How would this affect the system if the user decided to change the email address in the future or for some reason the email address simply becomes obsolete.
The sub I think would be a decent choice to use as a key. However, whenever I am thinking about primary keys I'm always thinking a million years in the future.
Ultimately I would choose a key that will forever be unique throughout the org eliminating the possibility of any future conflicts or in your case, confidentiality issues.
I tried google, but its not what I want. Google says, its a gathering to check how securely a signing key is stored based on distributed access to the key.
I have this class which has 3 Strings(broken key) and respective attributes (key check values, zone key check values, encryption master key). Using which I derive a Master key. I cannot put up the code here, as it violates my security policy. btw this is for smart cards.
If any one has any idea of this, please explain or point me to it.
OK, I'm going to be assuming a simple symmetric key (3DES or AES) split into 3 parts here. I can only answer because I make this assumption.
A key value is randomly generated, this is the key you're going to protect. Lets call this key the master key. A KCV (key check value) is calculated over the master key, so if it is regenerated the correctness of the key can be verified with relatively high certainty without revealing the value itself. The KCV doesn't leak information about the key material itself as the calculation of the KCV is one way.
This key is split into three parts using other random values and XOR. First two other random keys are generated. The third key is calculated to be the XOR of the other keys and the master key. KCV values are calculated and written down. The three keys can now be distributed to 3 different actors. These actors are called key managers in the role they perform in the ceremony. Commonly the key managers secure access to their key.
Now to regenerate the master key each key manager writes down their part of the key. The KCV of the key is verified before proceeding to make sure that no input errors have been mode, or that the value is not that of a different key. Now if you calculate the XOR of the three keys then you'll get the master key again. This value is again compared to the master key.
So that's all there is to it.
With regards to the security of this scheme:
you need all three keys as the other keys basically provide a One-Time-Pad encryption over the key value, which provides a very strong notion of security
the common KCV is a dangerous notion, as an encryption of an all zero block - the most common scheme - may leak sensitive information (e.g. for counter mode security with a zero nonce and counter). E.g. a HMAC over an empty value may be a better idea
obviously you need a secure random number generator to generate the keys or your scheme is likely to be insecure
it will be hard to generate the wrong key on purpose; commonly the KCV is three bytes, so the chance of one or two people colluding and generate the KCV of the master key is 1 in 2^24 (2^24 is over 16 million).
Key Ceremony in cryptography means that how you will activate your Signing key for different purpose like CA key when issuing a certificate. Key Ceremony have very strong security level that a key is activate with m of n rule, key is stored on secure physical location in Laptops or in HSM(hardware to store keys).
For more detail see WebTrust Principles and Criteria for Certification Authorities – v2.2 document ,download from http://www.webtrust.org/principles-and-criteria/docs/item83987.pdf, in section 4.4 CA Key Usage
On a high level, It's a process of rotating the cryptography keys on Production/UAT environment between two entities and then one entity send a request to another entity to make a session between them with the help of the keys. Keys can have certain roles to encrypt/decrypt the message, to check the integrity of the message e.t.c.
I have a question about when AES generate a key and IV how would the user know what the key is or how the program would know which key to use like it is generated. For example like if there is a encryption method that encrypt the file and generate the key and IV. When the program restarts or be used another day they would want to use the decryption but how would you know or the program knows thats the key for that file.
I understand the decryption and encryption by looking at it. I just dont know where the information is store to retrieve the key?
Key management is a large part of any cryptography related protocol. It takes a book or so to explain.
One of the most known methods is using a password (see password based encryption in PKCS#5, where a key is generated from a (stored) salt, number of iterations and of course the password (encoded to bytes). Another option is to store the key on some removable device like an USB key.
Usually the main key is not used to encrypt the data, but an intermediate key called the data or session key is used. For instance PGP encryption generates a data key and encrypts it with a public key of an asymmetric key pair.
Then there are smart cards, TPM modules, HSM's, key containers (possibly provided by the OS), key sharing protocols etc. etc. etc..
So ... it depends.
Sometimes it is easier to think of a key as another secret. By encrypting something you've only "compressed" your larger secret (your plaintext) into a smaller secret (the key) that you have to keep and manage. This secret however may have been generated in advance, or may have been generated by other means. If you just generate your key at the same time and location as your ciphertext, you haven't solved anything yet, you only made your secret smaller.
It's easier for the IV, the IV can simply be stored with (commonly, in front of) the ciphertext.
I have a situation where my application creates a hash based on it's serial number(for example: A1C2-E3G-4I5K). The serial is known to the user. The hash will also be known to the user. What is the best strategy to hash the data while making it impossible/extremely difficult for the user to create the hash themselves?
I am using the hash as a way of showing that an action has taken place on the remote application.
I have thought about private Key encryption, but it could be possible for the user to get hold of the private key themselves.
You could look into a Keyed-HMAC. Basicly you create a lets say SHA-256 hash on your value plus a secret key, only known to your application. With that assumption user will not be able to create valid hash for his own.
You could try "salting" the serial number before hashing it
http://en.wikipedia.org/wiki/Salt_%28cryptography%29
I have a security number generator device, small enough to go on a key-ring, which has a six digit LCD display and a button. After I have entered my account name and password on an online form, I press the button on the security device and enter the security code number which is displayed.
I get a different number every time I press the button and the number generator has a serial number on the back which I had to input during the account set-up procedure.
I would like to incorporate similar functionality in my website. As far as I understand, these are the main components:
Generate a unique N digit aplha-numeric sequence during registration and assign to user (permanently)
Allow user to generate an N (or M?) digit aplha-numeric sequence remotely
For now, I dont care about the hardware side, I am only interested in knowing how I may choose a suitable algorithm that will allow the user to generate an N (or M?) long aplha-numeric sequence - presumably, using his unique ID as a seed
Identify the user from the number generated in step 2 (which decryption method is the most robust to do this?)
I have the following questions:
Have I identified all the steps required in such an authentication system?, if not please point out what I have missed and why it is important
What are the most robust encryption/decryption algorithms I can use for steps 1 through 3 (preferably using 64bits)?
Your server has a table of client IDs and keys. Each client also knows its own key.
The server also maintains a counter for each client, initialised to zero. Each client maintains a counter, also initialised to zero.
When the button is pressed on the client, it generates a HMAC of the current counter value, using its key as the HMAC key. It generates an alphanumeric code from the HMAC output and displays that to the user (to send to the server). The client increments its counter value.
When an authentication request is recieved by the server, it repeats the same operations as the client, using the stored key and counter for that client. It compares the alphanumeric code it generated with the one recieved from the client - if they match, the client is authenticated. If they do not match, the server increments its counter for that client and repeats the process, for a small number of repetitions (say, ~10). This allows the server to "catch up" if the client counter has been incremented without contacting the server.
If the counter rolls over to zero, the server should not accept any more authentication requests for that client ID, until it is issued a new key.
There are extensions to this basic protocol: For example, instead of a counter, you can use synchronised clocks on the server and client (with the value changing every N seconds instead of every button press).
What you're describing is called an HOTP, or HMAC-based One Time Password. Implementation is described in this RFC, and unless you have a compelling reason not to, I'd strongly suggest implementing it as-is, since it's been vetted by cryptographers, and is believed secure. Using this will also give you compatibility with existing systems - you should be able to find HOTP-compatible tokens and software apps, like Google Authenticator for Android.