cards which are shared with the client machine the emulator is running on, or
the cards could be pure software constructs.
-The emulator is structured to allow multiple replacable or additional pieces,
+The emulator is structured to allow multiple replaceable or additional pieces,
so it can be easily modified for future requirements. The primary envisioned
modifications are:
--------------------
Replacing the Socket Based Virtual Reader Interface.
-The current implementation contains a replacable module vscclient.c. The
+The current implementation contains a replaceable module vscclient.c. The
current vscclient.c implements a sockets interface to the virtual ccid reader
on the guest. CCID commands that are pertinent to emulation are passed
across the socket, and their responses are passed back along that same socket.
the emulator.
An application that wants to use the virtual reader can replace vscclient.c
-with it's own implementation that connects to it's own CCID reader. The calls
+with its own implementation that connects to its own CCID reader. The calls
that the CCID reader can call are:
VReaderList * vreader_get_reader_list();
VReader * vreader_list_get_reader(VReaderListEntry *)
This function returns the reader stored in the reader List entry. Caller gets
- a new reference to a reader. The caller must free it's reference when it is
+ a new reference to a reader. The caller must free its reference when it is
finished with vreader_free().
void vreader_free(VReader *reader);
- This function frees a reference to a reader. Reader's are reference counted
+ This function frees a reference to a reader. Readers are reference counted
and are automatically deleted when the last reference is freed.
void vreader_list_delete(VReaderList *list);
VReaderStatus vreader_power_on(VReader *reader, char *atr, int *len);
- This functions simulates a card power on. Virtual cards do not care about
+ This function simulates a card power on. A virtual card does not care about
the actual voltage and other physical parameters, but it does care that the
card is actually on or off. Cycling the card causes the card to reset. If
the caller provides enough space, vreader_power_on will return the ATR of
unsigned char *receive_buf,
int receive_buf_len);
- This functions send a raw apdu to a card and returns the card's response.
+ This function sends a raw apdu to a card and returns the card's response.
The CCID front end should return the response back. Most of the emulation
is driven from these APDUs.
int cert_count);
The parameters for this are:
- card - the virtual card structure which will prepresent this card.
+ card - the virtual card structure which will represent this card.
flags - option flags that may be specific to this card type.
cert - array of binary certificates.
cert_len - array of lengths of each of the certificates specified in cert.
cert_count - number of entries in cert, cert_len, and key arrays.
Any cert, cert_len, or key with the same index are matching sets. That is
- cert[0] is cert_len[0] long and has the corresponsing private key of key[0].
+ cert[0] is cert_len[0] long and has the corresponding private key of key[0].
The card type emulator is expected to own the VCardKeys, but it should copy
any raw cert data it wants to save. It can create new applets and add them to
VCardStatus vcard_add_applet(VCard *card, VCardApplet *applet);
Add an applet onto the list of applets attached to the card. Once an applet
- has been added, it can be selected by it's aid, and then commands will be
- routed to it VCardProcessAPDU function. This function adopts the applet the
- passed int applet. Note: 2 applets with the same AID should not be added to
- the same card. It's permissible to add more than one applet. Multiple applets
+ has been added, it can be selected by its AID, and then commands will be
+ routed to it VCardProcessAPDU function. This function adopts the applet that
+ is passed into it. Note: 2 applets with the same AID should not be added to
+ the same card. It is permissible to add more than one applet. Multiple applets
may have the same VCardPRocessAPDU entry point.
The certs and keys should be attached to private data associated with one or
apdu->a_Le - The expected length of any returned data.
apdu->a_cla - The raw apdu class.
apdu->a_channel - The channel (decoded from the class).
- apdu->a_secure_messaging_type - The decoded secure messagin type
+ apdu->a_secure_messaging_type - The decoded secure messaging type
(from class).
apdu->a_type - The decode class type.
apdu->a_gen_type - the generic class type (7816, PROPRIETARY, RFU, PTS).
The expected result of any APDU call is a response. The card type emulator must
set *response with an appropriate VCardResponse value if it returns VCARD_DONE.
-Reponses could be as simple as returning a 2 byte status word response, to as
+Responses could be as simple as returning a 2 byte status word response, to as
complex as returning a block of data along with a 2 byte response. Which is
returned will depend on the semantics of the APDU. The following functions will
create card responses.
VCardResponse *vcard_make_response(VCard7816Status status);
This is the most basic function to get a response. This function will
- return a response the consists soley one 2 byte status code. If that status
- code is defined in card_7816t.h, then this function is guarrenteed to
+ return a response the consists solely one 2 byte status code. If that status
+ code is defined in card_7816t.h, then this function is guaranteed to
return a response with that status. If a cart type specific status code
is passed and vcard_make_response fails to allocate the appropriate memory
for that response, then vcard_make_response will return a VCardResponse
of VCARD7816_STATUS_EXC_ERROR_MEMORY. In any case, this function is
- guarrenteed to return a valid VCardResponse.
+ guaranteed to return a valid VCardResponse.
VCardResponse *vcard_response_new(unsigned char *buf, int len,
VCard7816Status status);
int vcard_emul_get_login_count(VCard *card);
- This function returns the the number of remaing login attempts for this
+ This function returns the the number of remaining login attempts for this
card. If the card emulator does not know, or the card does not have a
way of giving this information, this function returns -1.
VCard7816Status vcard_emul_login(VCard *card, unsigned char *pin,
int pin_len);
- This function logins into the card and return the standard 7816 status
+ This function logs into the card and returns the standard 7816 status
word depending on the success or failure of the call.
void vcard_emul_delete_key(VCardKey *key);
The options structure is built by another function in the virtual card
interface where a string of virtual card emulator specific strings are
- mapped to the options. The actual structure is defined by the virutal card
+ mapped to the options. The actual structure is defined by the virtual card
emulator and is used to determine the configuration of soft cards, or to
determine which physical cards to present to the guest.
cert_len, and keys are all arrays of length cert_count. These are the
the same of the parameters xxxx_card_init() accepts.
- Finally the card is associated with it's reader by the call:
+ Finally the card is associated with its reader by the call:
VReaderStatus vreader_insert_card(VReader *vreader, VCard *vcard);
projects / qemu.git / blobdiff