initial

1 files changed, 107 insertions, 0 deletions

diff --git a/README b/README
new file mode 100644
index 0000000..b003171
--- /dev/null
+++ b/README
@@ -0,0 +1,107 @@
+How the code is structured to support a CCID reader front end, though any 
+reader that support 7816 cards will need similiar functions.
+
+The calls that the virtual reader front end can call are:
+
+VReaderStatus
+vreader_get_reader_list(VReaderList **list) -
+
+returns a list of virtual readers.  These readers may map to physical devices,
+or simulated devices depending on vcard the back end. Each reader in the list 
+should represent a reader to the virtuall machine. Virtual USB address mapping 
+and device naming is left to the CCID reader front end.
+
+VReaderStatus
+v_reader_power_on(VReader *reader, char *atr, int **len) - 
+
+simulate a card power on. Virtual cards do not care about the actual voltage 
+and other physical parameters, but it does care that the card is actually on 
+or off. Power on returns the ATR of the virtual card.
+
+VReaderStatus
+vreader_power_off(VReader *reader) - 
+
+power off a virtual card.
+
+VReaderStatus
+vreader_xfer_bytes(VReader *reader, unsigne char *send_buf, int send_buf_len,
+                   unsigned char *receive_buf, int receive_buf_len) -
+
+send a raw apdu to a card and get a response. The CCID front end should return
+the response back to the 'host'.
+
+VReaderStatus
+vreader_wait_for_status_change(VReaderList *list) - 
+
+should be made on a new thread by the reader front end. The back end will 
+return if there are any state changes to the readers on the list (including 
+reader insertions, reader removals, card insertions, or card removals). The 
+reader front end can use this to generate Interupt-IN messages.
+
+
+---------------------------------------------------------------------------
+
+The code creates a virtual CAC card. Most of the simulation is APDU processess.
+card_7816.c implements the common instructions processing for 7816 cards. 
+Currently only VM cards are simulated. No Secure messaging APDUs are simulated,
+however. These are usually used for card provisioning and requires cards and
+back end servers to share keys. 
+
+
+Describe the ADPU structure.
+
+
+Describe the Response structure.
+
+
+Describe the applet select mechanism.
+
+
+
+card_cac.c implements the cac specific applets. Only those applets needed by
+the coolkey pkcs#11 driver on the guest have been implemented. To support the
+full range CAC middleware, a complete CAC card according to the CAC specs 
+should be implemented here. To create a virtual piv or virtual coolkey, a 
+similiar .c file could be added which implements the applets on those cards.
+
+
+-----------------------------------------------------------------------------
+
+card_emul back end. The following calls make up the smart card back end. The
+current implementation uses NSS so supply the appropriate functionality. This
+allows not only real smart cards on the host to be used, but also smart cards 
+simulated by certs and keys in the users NSS database, or in PEM files. The NSS
+implementation could be replaced by a CAPI or direct to PKCS #11 
+implementation.
+
+/*
+ * Login functions
+ */
+/* return the number of login attempts still possible on the card. if unknown, return -1 */
+int card_emul_get_login_count(VCard *card);
+/* login into the card, return the 7816 status word (sw2 || sw1) */
+VCard7816Status card_emul_login(VCard *card, unsigned char *pin, int pin_len);
+
+/*
+ * key functions
+ */
+
+/* delete a key */
+void card_emul_delete_key(VCardKey *key);
+/* RSA sign/decrypt with the key, signature happens 'in place' */
+VCard7816Status card_emul_rsa_op(VCard *card, VCardKey *key,
+                                 unsigned char *buffer, int buffer_size);
+
+void card_emul_reset(VCard *card, VCardPower power);
+
+/*
+ * still need initialize, card insertion/removal status, get the list of valid reader
+ * insertion/removal may need to be a thread that returns insertion/removal events
+ */
+void card_emul_initialize();
+
+
+
+
+
+