answer second q

main.typ

@@ -19,8 +19,8 @@
   fill: green.lighten(60%),
 )[#text]
 #show: config.with(
-  course-name: "UE Sequence Analysis and Phylogenetics
+  course-name: "Smart Cards & NFC
-Exercise 15",
+  Homework 2: Smart Card Protocols",
   serial-str: "k12104785",
   author-info: [
     Lukas Heiligenbrunner
@@ -258,4 +258,131 @@ Exercise 15",
   + Is there any potentially security-critical data transmitted unencrypted? E.g. a password or PIN, private keys (of cryptographic key pairs), etc.
   + Could the data extracted from this trace be abused by an attacker who stole that card? Why? Why not?
   + Could the data extracted from this trace be abused by an attacker who does not have physical access to the card? Keep in mind that some online shops only ask for a credit card number (but no verification code) when you pay. Hint: What’s a “PAN”?
-][]
+][
+  Here is documentation of the instruction set of the ISO/IEC 7816-4 standard:
+
+  #figure(
+    image("rsc/instructionsets.png", width: 50%),
+    caption: [],
+  ) <instrset>
+
+  + What is going on in the trace? What commands are sent? What data is returned?
+
+    In the first instruction, the terminal sends a SELECT (CLA=00, INS=A4) command.
+    This command selects a file or application on the card.
+    The card responds with a file control information (FCI) template.
+
+    #figure(
+      image("rsc/selectcmd1.png", width: 50%),
+      caption: [Response of this command],
+    )
+
+    The response contains an *IBAN* and *BIC* code, so it seems to be some kind of banking card.
+
+    In the second instruction (00B2012C00): READ RECORD (CLA=00, INS=B2) a specific record of the card is read (0x012C00).
+    #figure(
+      image("rsc/moreinfo1.png", width: 50%),
+      caption: [Response of record request],
+    )
+    So now we know this is a *VisaCredit* card.
+    THE Application identifier is A0000000031010.
+
+    The next instruction (00B2022C00) does basically the same and requests another record.
+    The card returns an error code (6A83) which means "Record not found".
+
+    The next instruction (00A4040007A000000003101000) SELECT (CLA=00, INS=A4) selects the application read in the previous command.
+    #figure(
+      image("rsc/selectcmd2.png", width: 50%),
+      caption: [Response of second SELECT command],
+    )
+    It returns similar infos than the command above.
+
+    Next the 80A8000002830000 command is sent (GENERATE APPLICATION CRYPTOGRAM (CLA=80, INS=A8)).
+    This command is responsible for generating dynamic cryptographic data.
+    #figure(
+      image("rsc/cryptoresp.png", width: 50%),
+      caption: [Response of the crypto command],
+    )
+    The result seems to contain some cryptographic data, maybe a random key.
+
+    Thge next 7 instructions (00B2xxxx) are very similar and read records. (READ RECORD (CLA=00, INS=B2)).
+    #subpar.grid(
+      figure(image("rsc/moreinfo2.png"), caption: []),
+      figure(image("rsc/moreinfo3.png"), caption: []),
+      figure(image("rsc/moreinfo4.png"), caption: []),
+      figure(image("rsc/moreinfo5.png"), caption: []),
+      columns: (1fr, 1fr, 1fr, 1fr),
+      caption: [],
+    )
+    #figure(
+      image("rsc/moreinfo6.png", width: 100%),
+      caption: [Response of the crypto command],
+    )
+    #figure(
+      image("rsc/moreinfo7.png", width: 50%),
+      caption: [Response of the crypto command],
+    )
+    #figure(
+      image("rsc/moreinfo8.png", width: 100%),
+      caption: [Response of the crypto command],
+    )
+
+    The commands read more informations like *card holder*, *application version*, *application expiration date*.
+
+    The next command (0020008008243653FFFFFFFFFF) is VERIFY (CLA=00, INS=20).
+    This seems to verify a PIN entered in the terminal.
+
+    As from the documentation of the standard:
+    In this group of commands, SW1-SW2 set to '63CX' indicates a successful change of memory state, but after
+    an internal retry routine; 'X' > '0' encodes the number of retries; 'X' = '0' means that no counter is provided.
+
+    This means in our case the command is sent 3 times and and we get three different responses:
+    - 63C2 -> 2 retries left
+    - 63C1 -> 1 retry left
+    - 9000 -> success
+
+    This means the pin is entered wrong 2 times the counter to freeze the card was decreased and on the third try the card was unlocked.
+
+  + What files/applications are accessed? Can you determine specific application and file IDs? What are these IDs?
+
+    Applications accessed:
+    - 315041592E5359532E4444463031 -> payment system application
+    - A0000000031010 -> VisaCredit application
+
+  + What type of card could this be?
+
+    This is a VisaCredit card for payments.
+
+  + Is there any potentially privacy-critical data transmitted unencrypted? E.g. personal data, identifying data, account numbers, etc.
+
+    Yes, there is several personal data transmitted unencrypted:
+    - IBAN: 44453032313230333030303030303030303030303030
+    - BIC: 42594C4144454D31303031
+    - Card holder name: R O L A N D / M I C H A E L
+    - Application primary account number: 4548180123445500
+    - Expiration date:080731
+
+  + Is there any potentially security-critical data transmitted unencrypted? E.g. a password or PIN, private keys (of cryptographic key pairs), etc.
+
+    One command that might leak private infos is 80A8.
+    #figure(
+      image("rsc/cryptocmdinfo.png", width: 50%),
+      caption: [Informations about the 80A8 command],
+    )
+
+    This seems to verify the digital signature of the card.
+    The response might be a cryptographic key which could be used to exploit something?
+
+  + Could the data extracted from this trace be abused by an attacker who stole that card? Why? Why not?
+
+    The attacker could use the PAN or expiration date for online transactions.
+
+  + Could the data extracted from this trace be abused by an attacker who does not have physical access to the card? Keep in mind that some online shops only ask for a credit card number (but no verification code) when you pay. Hint: What’s a “PAN”?
+
+    PAN is the primary account number and is the number on the front of the card.
+
+    Yes, if an attacker has this trace he could:
+      - Use the PAN and expiration date for online transactions. -> if no verification code is needed
+      - Use the track data to produce magnetic stripe clones.
+      - Use the card holder name for social engineering attacks.
+]