Can someone explain the usage for the following EMV keys:
- MDK Encryption Key
- MDK MAC
- MDK AC
And what is the relation between these keys and MAK-AC, MK-SMI and MK-SMC
I can't find any reference to MDK in EMV Book 2 – Security and Key Management
EMV was implemented to make the transaction most secure and these keys do their part in
Integrity, Confidentiality and Security aspect of it. As it sounds
Integrity is to make sure the data is not altered on transit
Confidentiality to make sure only the right person can access it
Security to ensure that it came from whom you think it is.
The heirarchy is Issuer Master Key -> Card Master Key -> Session Key.
AC is for cryptogram(ARQC), SMI for MAC(pin unblock issuer script) , and SMC(pin change issuer script) to encrypt for confidentiality.
You may derive all the keys from same IMK or different, so that makes it them related or different. You can find more information in Book 2. Look closer. At times it will be boring, but it is worth it.
EMV card uses different keys for different purpose. Keys - AC, SMI and SMC are basic keys that must be personalize in the card where AC key are more frequently used than other key SMI and SMC.
Why AC key is mostly used?
In case transaction goes online, AC key used to compute cryptogram and this cryptogram passed to HOST, host calculate the cryptogram and will match with the received one i.e. Host should have the same AC key.
what about SMI and SMC keys?
In simple term - what if user entered wrong pin multiple time,here card will be blocked, here issuer will send a script and that script will be execute to un-block the pin, we can say SMI and SMC is used for Issuer Scripting.
Secure messaging for confidentiality is used when the command data sent to the card must
be encrypted to protect sensitive data.[ sensitive data = new pin]
Related
I am writing a data management system with Hyperledger Composer. I know about .acl- and .cto-files, but I have no idea how I would go about adding (and saving) permissions via transactions (=during runtime).
Example use case:
A Patient allows a particular Physician to look at his data. The permission is saved, and the Physician can look at the data of the Patient.
The Patient withdraws his permission. The Physician can no longer look at the data.
One could save a list of all patient permissions for every physician, and make it a Patient-only transaction to add their name to the list, but the Modeling Language does not allow lists, only arrays.
Does someone have an idea? :)
suggest to check out the Composer sample networks for code samples - this PII (Personally Identifiable Information) network has similarities to what you're trying to achieve (controlling access to a patient record by the identifier of (in this case) the Physician) https://github.com/hyperledger/composer-sample-networks/blob/master/packages/pii-network/lib/logic.js .
Your ACLs can obviously be written to control access to the Patients record (ie he/she has consented) and only allow a matching Physician identifier to access, based on a condition check in the ACL - an example of use of something similar can be found in this Stack Overflow here -> Hyperledger-Composer: ACL-rules with condition of type (r.someArray.indexOf(p.getIdentifier()) > -1) not working
I would say its better to have an array of authorized Physicians per patient (ie a lot less than the converse where a physician might have a lot of patient IDs to check each time). Your array size is a javascript constraint in theory (heap size etc) but see discussion here -> Maximum size of an Array in Javascript
I was working on developing a RESTful service where the Id of a particular table in the database needs to be returned to the client for future access to the particular entry in the database. I was advised against using auto increment and returning the id directly and hence I went for encrypting and sending the Id in the following manner instead -
SET #secretKey1 = "some key";
SET #secretKey2 = CONCAT("some other key", AccountNo);
SET #encryptedAccountNo = TO_BASE64(AES_ENCRYPT(AccountNo, #secretKey1));
SET #encryptedId = TO_BASE64(AES_ENCRYPT(Id, #secretKey));
RETURN CONCAT(#encryptedAccountNo, #encryptedId);
(Note: The Account Number is a sufficiently random field not exposed to the client)
Would using UUID as the primary key be more appropriate? If so, is using the UUID enough or should that be encrypted too?
Or would you use some other design entirely?
Also, do you have any tips for improving the security or performance aspects of the existing design?
I think you may have misunderstood that advice....
When you say "I was advised against using auto increment and returning the id directly".
You should certainly always CHECK the Id is correct to use server side, before using it;
(i.e. check that the document with that Id belongs to the user who is trying to edit it),
but encrypting the ID itself really serves no useful purpose as your API will have to deal with the encrypted one (unless you are encrypt/decrypt client side, which does nothing for security), so the (malicious) client can just send the encrypted version and have the exact same result...
We cannot comment of the security of your code from looking at a (small) piece of your database logic. If you want proper review you will have to post the code that actually does the interaction...
I need to Validate SSN in such a way that redundant entry should not appear. for example if a message arrives for Patient A with ssn 123-45-6789 and next time if any message comes for Patient B with same ssn, integration engine should catch this. I am using cloverleaf as a integration engine and need to validate this.
please let me know if any logic can be suggested.
Thanks,
Anupam..
That wouldn't be a valid use case for an integration engine. You should look into acquiring a master patient index application and integrate it into your message flow.
Even then, with HL7 messaging there is generally no 100% reliable source of truth to tell you who is Patient A and who is Patient B. For example, if you get a second message for SSN 123-45-6789 and the name doesn't match the first patient is that because it's really a different person or did the patient perhaps legally change her name?
Finally relying on SSNs in health care systems is generally considered a bad idea due to the security and privacy concerns. Most modern systems actually filter out SSNs and rely on other fields to identify the patient.
I'm puzzled and looking for a way out here. I will appreciate any help:
I am sending notifications from a server to Android devices using GCM. In Mysql, I have a User Table (UT) with user ID, user data and GCM registration ID. I also have a User Notifications Table (UNT) in which I store the notification types that each user is registered to. This table includes the user ID and the notification type ID.
When Sending the notification, I need to go through UNT and build an array of all user IDs that are registered to this type of notification. Then I need to go through the UT and get the GCM Registration ID for each user and send the notification.
DB design-wise, I believe that this is the right way to do it. However, in notification sending, speed is a major issue if I want a million users to get the notification a few seconds after sending it. Going through 2 tables significantly increases the processing time (I measured 47 seconds for 1 million users when going through both tables compared to 17 seconds when going through 1 table).
The question is will it be right to store the GCM registration ID also in the UNT so I won't have to go through the UT? Again... DB design wise it is incorrect but GCM wise, it might be the best solution.
If you know of additional methods to solve this issue, I'll be happy to hear about it.
Thank you
You can always decide to hold data redundantly. Yes, this means de-normalizing data, but is something that is often done when you need quick access to many data - in data warehouses for instance.
The dbms even supports this by ON UPDATE CASCADE. But GCM registration ID must be unique in the table.
So either it is unique in UT, then just add the field in UNT, fill it, and create the foreign key with the cascade option.
Or it is not unique in UT, then you need a GCM table (which you should have then anyhow) and have this foreign key from UNT to GCM then. (But in this case you would have to think about if it is really a user notification table you need or a a GCM notification table or both.)
I want to create a user management system for my site ,
what is better for security and performance .
Type 1 :
table_user : user_id , user_name , user_email , user_password . user_phone ...
or
Type 2 :
table_user : user_id , user_name , user_email ...
table_pass : user_id , user_password .
table_phone: user_id , user_phone .
which one is better ?
Ideally:
Don't store passwords at all (even encrypted). Store hashes derived from passwords.
Salt the passwords to prevent rainbow attacks.
Put hashes on a separate database server, behind its own firewall and its own well-defined API1. This API should do only three things:
For given username, retrieve the corresponding password hash.
For given username, set the new hash (to support resetting the password).
Remove given username and its hash (to support user unregistration).
Do the same for salts: put them on their own server and behind their own firewall and API. This API should do only three things:
For given username, retrieve the corresponding salt.
For given username, set the new salt to a random value (to support resetting the password).
Remove given username and its salt (to support user unregistration).
Both hash and salt servers should be cut-off from the world (and from each other) and only accessible from the server that runs your Web application (i.e. PHP or ASP.NET or whatever...).
When user tries to log-on by entering username and password:
Make sure this is done through HTTPS so the entered data safely reaches your server.
Call the API that retrieves the password hash for the username.
Call the API that retrieves the salt for the username.
Salt and hash the password entered by the user and compare it to the retrieved hash.
If they match, user is granted the access.
By their nature, hashes are irreversible - other than the user, nobody, not even you, knows the exact password. In case the user forgets the password, you can't send the password to them, but you can allow them to reset the password assuming they pass some additional verification (i.e. have access to a particular e-mail address and/or answer a secret question).
BTW, log-on is a relatively rare operation, so it's unlikely to pose a performance bottleneck unless you completely disregard proper indexing.
1 E.g. implement a Web Service, then open only the port needed for that Web Service and nothing else.
I will go with option 1.
Think there are lakhs of users. So to get the user data you will have to deal with n tables instead of 1 table, which obviously add LOAD on server and finally you will have BAD PERFORMANCE.
So, I would go with option 1.
For tel. number, add field as landline_number, mobile_number, alternate_number as adding field in table won't make that much difference then adding table for the field.
And yes, as per Steve comment, store password using secure hashing mechanism.
So what option are you going to choose?
Firstly, as #Steve comments, you should store passwords using a secure hashing mechanism - storing plain text passwords is irresponsible - it means that anyone who can hack into your system knows user passwords which they may have re-used on other sites.
Secondly, there is no inherent security or performance benefit in either design - from a security point of view, you have to assume that an attacker who can get access to your database can run queries, and it would be trivially easy to retrieve data in both schemes. From a performance point of view, the cost of the joins in option 2 is unlikely to matter if you have primary/foreign key indices.
If you have requirements to re-set passwords after a certain period, and you need to store password history to prevent people re-using passwords (this is a feature Windows supports, for instance), you need to go have a "UserPassword" table, with valid_from and valid_until columns.
It depends. If you would like to keep password history and if user can have many telephone numbers then you create additional tables for passwords and phones. In other case one table is enough.