I'm working on the AFC (automatic fare collection) system which required a SAM( secure access module) for key management.system works fine with local key management in MCU and I don't have any experience in using SAM.SAM required to install beside MCU as main reader controller & contactless card reader chip(PCD).
Is used protocol based on the smart card ISO7816?Am i true?
As i know SAMs are part of SMART cards family,are a SAM javacard or there are javacard SAM and non javacard SAM?
is there upper level standard used for communicating with SAMs(based on iso7816 ) or each manufacturer use its own protocol?
whats different between SAM and usual GSM SIM-CARD? and can i use a GSM-SIMCARD instead of SAM?
is there any standard use case for process of key management in smart cards ?
wbr
A SAM may be a smart card or another chip like a trusted platform module. A TPM is addressed using an API, see here.
SAMs are seldom required, so there are no domain independent standards how to address these.
If a smart card is used, then 7816 is obviously the way to go. A native smart card is also perfectly possible as SAM, especially if Perform Security Operation command of ISO 7816-8 is supported.
A typical SAM command is "encrypt these data with your (say AES) key number 1". A typical SIM card will have no command for it.
You have to collect the use cases you are interested in by yourself. Some ideas:
encrypt these data
decrypt this cryptogram
compute or verify this message authentication ocde
derive session key
replace key data of existing key
Related
I've my C# NET6 desktop application to send to customers, important functions have been removed and implemented on a server
I've my public server on which I want to auth desktop app(license, feature...), get its blob, process it, send back
I consider the C# app crackable whatever obfuscator/protector I'll use (but i'll use anyway), server is considered secure, i need a secure point at customer premise.
The idea is to use an usb dongle to bring up a secure and authenticated session between desktop app and server.
Requisites for the dongle are:
Be able to do AES128(at least) and/or RSA1024(at least)
EAL5+/6+ secure MCU (nothing that could be dumped with glitches or baths in acid)
dll and API to talk with
So far i've looked at various sw protection dongle, but:
some are 15years old mcu and not sure if still in business
most doesn't tell what mcu is inside, some are fast (but silly) stm32, some are slow 8051
the expensive ones are the most complex ones, i mean it takes days to read unclear documentation and see that i don't need 90% of the package (enveloper, mssql db for my 50customers...)
i don't need at all their C# enveloper, I want to use a thirdparty/specific protector with VM
So i've looked at usb tokens PKI, FIDO2, PIV....but:
FIDO2 allows customer to reset pin and cear all certificates, no good as i want to burn keypair inside prior to ship to customer
PIV not found any cheap PIV only usb token, some FIDO2 expensive has also PIV interface, but...
to talk to FIDO2 and PIV i would need all the overload bloat of libraries that i very dislike (and also needs admin right, which i want to avoid)
PC/SC usb token are the most lowlevel to use, mscard lib and do whatever, nice but.....ISO-7816-8,9 are not public, costs like 300bucks to eventually see that my card vendor implemented custom stuff
I've 0x80 blob to send to dongle to powmod() it, that's all, no x509, no pkcs11, no base64, nothing human, just need a powmod(data) or an aes_dec(data).
Any suggestions?
While this is no full answer, I would like to address some issues:
You may underestimate the complexity required. Obviously necessary is some specification, whether RSA or AES operation is required. This has to show up somewhere, either as command parameter or as a set-up command (between host and connected token).
Pure modular exponentiation is unlikely to reach the desirable level of security, since RSA depends on padding to exclude some kinds of attack.
You may not like PKCS 11 interface, but it is proven and known to introduce no security issues. This may require notable effort if done on your own.
Given the mentioned EAL levels, my guess would be, that you need a smart card chip with USB interface.
The MCU is pretty irrelevant: to get crypto operations hardened, you need special hardware (as cryptographic coprocessors). It has little influence, how old the architecture of the chip is, which feeds the bytes to those.
I am trying to develop a custom cryptographically secure protocol for authenticating through an RFID smart card, all I can find over the internet are generic info on how write static Tags into the card.
For my project I need for the reader to send a Challenge nonce to the card (fixed length random bytes), then the card should send back the challenge encrypted with the hard-coded key (for example with AES CBC) or an hash HMAC.
The problem is: how can I program the card to do such behavior? I can write the code to do so, but how to "flash" it to the card. Also the code for the reader is not a problem (I want to use an Arduino with a reader module).
And then has a passive chip enough power to do this kind of calculations or is better to use an active one, considering that the distance would be few centimeters, such as behind a door?
A passive tag can't do this. Those just hold serial numbers that they spit out back.
You need some smarter card. You have basically two choices:
1) Choose a general-purpose card that fit your needs
The authentication scheme you describe is very widely used, and implemented by virtually all general-purpose smart cards, whether with contact or contactless (RF) interfaces (or both). If you go this way, you don't need to program the card with your own code, you just need to get the specs and initialize the card with the key value you want by sending the appropriate commands. And actually, with these cards, there are often generic tools available to initialize them. Easy.
Mifare (by NXP), for example is very widely used, easily available, and cards are cheap (drawback: it is certainly not the most secure cards ever made). You could use Mifare Classic - with proprietary NXP security protocol - specs here (be careful, the reader must be compatible) or Mifare UltraLight C, with open 3DES crypto - specs here. There are other variants, as well (e.g. Mifare Plus, which uses AES). Just don't go for the simple Mifare Ultralight, which doesn't provide authentication means. You'll see that for all these type of cards, there is a builtin authentication scheme that can functionally fulfill your needs (it is actually a mutual authentication, so it does more that what you require, but it's fine).
FeliCa (made by Sony), ACOS3 (made by ACS - specs here) are other possibilities, although I'm less familiar with it.
2) Get programmable cards
There are some, but it is not very easy to find for contactless and they are very expensive. You can lookup:
BasicCard (ZeitControl), which exist with dual interface. Those cards are programmable in Basic, and there are some kits available (but I'm not familiar with it either).
JavaCard (any manufacturer), which is a standard, but those are hard to find for small volumes. A few online shops seem to have some, though. These cards are programmable in Java (actually a subset of Java). There are tools available for the development phase (from Oracle, or even as Eclipse Plugins, for example). Then, for loading your custom applet in the smart card, you need to get familiar with GlobalPlatform, which is another (publicy available) standard, describing the way applications are managed in a smart card. This would be too broad to describe in detail here, though. You can find resources on the internet, but this road is definitely the most difficult.
Note, that NFC just describes the communication method and tells nothing about the intelligence available on other side.
More intelligence is needed (the command you seem to look for is called EXTERNAL AUTHENTICATE in ISO 7816-4), but does not help for your range problem, since the weaker the field, the less power is available. The idea of having communication through the door will only work for doors which are so weak, that a high-tech electronic protection won't improve overall security. The maximum distance achievable with standard field strength (heart pacemakers and similar devices limit that one) with nothing more than air between suffices typically for something like 10 centimeters. So for me it seems that your reader has to be on the outside and needs to be mechanically hardened against tampering itself.
(What would help, is a "card" with its own power source, so the field is only required for communication. As far as I know, this is mostly provided by a sort of external sleeve.)
What dim fails to mention is the product group of so-called native cards, which are typically only programmable with significant manufacturer support (non-disclosure agreement, probably fee involved), but luckily contain functionality for most use cases already, in your case the commands Get Challenge and External Authenticate.
what's the current use of java cards? The documentation is either really old or really sparse.
After googling for some time, this is my perceived idea:
eID: signing document hash with private key, issued by central authority (government) - signing legal documents
unique ID - identification (of person) by ID, protected by PIN and secured by TLS
java connected edition web application - I've not been able to find any documentation for the usage of this, except template applications in IDEs. Why are APDU's still used when there's this layer available? Is the application for this non-existent?
Despite all the new functionalities, I see they're only used as identification for a central repository/provider? And the TLS is used to secure communication between the card and backend server?
Thanks.
SIM cards are usually Java Cards, banking cards from Mastercard and Visa are usually Java card, and so are many others. ePassports can be build using Java Card. There are secure elements within readers that are Java Card. Driver licenses, driver licenses, digital tachograph cards, access control cards, cards holding PGP keys, etc. etc. etc..
There are billions of Java Cards, and Java Card is the only reason why Java was claimed by Sun to be on 3 billion devices (and note that they will probably not count Android as that officially is not Java). Currently the JCF (Java Card Forum) is also pushing Java Card forward as secure / programmable element to be used in IoT devices.
eID can be and usually is used more than for just signing documents. It is mainly used for authentication. It may also be used just to verify specific attributes of a person such as his / her age. And it can of course be used to decrypt information if an encryption key pair is present.
So no, there are many more things that Java Card can be used for.
As for the connected edition: it requires highly expensive hardware (smart cards are products that rely on high volume where every cent matters). Furthermore, a lot of protocols are specified using APDU's: you cannot just replace that with HTTPS to the smart card without respecifying the protocols.
ISO/IEC 7816-4 is a horrible standard - if you can call it that - but it currently is the only broadly accepted one. Java Card RMI has not caught on either; I don't see why the connected edition will suddenly change that.
I wanted to create J2ME application, in which the application should work only with the SIM card that was used during installation. On SIM card (GSM) change the application should now work.
For achieving this, i thought of taking an signature of the simcard and save it in a persistent storage. On every start of the application the signature can be verified. Any idea of how to implement this.
Thanks in advance
The 'SATSA' (Security and Trust Services API aka JSR177) could be used from your J2ME application to communicate with the SIM. You could send '3GPP TS 11.11' commands to obtain the IMSI (select file DG_GSM, select file EF_IMSI, read binary).
Drawbacks are: (1) You're talking to the SIM on a relatively low level of abstraction (the ISO7816-4 layer); (2) Not all handsets support JSR177 at the moment.
I believe this is not possible. If it was possible with a specific phone it would not be possible in a generic way.
For ATT in US, for J2ME apps, the handset embeds "CarrierDeviceId" in the Jad file. This is unique per SIM card. So, if something similar is available to you, just read this Jad parameter the first time the app starts, save it to RMS or send it to server. Now each time the app starts, you can verify this number matches, and thus verify the SIM card is same.
You can also try obtaining the phone number that is tied to the SIM card and thus verify the old SIM is being used.
I am trying to sign an XML document with the Micrisift API for the smart cards...
So far I can list the card readers, connect to the right card and establish the context but after that I am not sure what is next......
What PC/SC Functions Do I need to call to sign a document with a private smartcard key?
thanks in advance
Javier
If you have a middleware installed you can use the Windows CAPI for cryptographic functions. Some middlewares also ship a PKCS#11 library you can use.
If you don't have any middleware you have to do it yourself using the PC/SC interface, I suggest you look into ISO/IEC 7816-4 and ISO/IEC 7816-8 if the card is using Secure Messaging (or Sado Machism if you ask me). Unfortunately those ISO specs are quite expensive, however you can find some excerpts from ISO/IEC 7816-4 right here.
The ISO/IEC 7816-4 describe the APDU commands for information exchange with the card. The PKCS#15 standard can also be of great help regarding how files are stored on the card.
Also, you might need the full specification from the card manufacturer. If you are lucky you can find a plugin for your card in the MuscleCard project or the OpenSC project (they both work in Windows too).