nimro97 / pv204_in_dr Goto Github PK

• Present the certificate analysis through Zoom conference

• Prepare slides for the report
• Generate pdf file for the slides
• Submit presentation to the MUNI Information System

• Derive session keys
• Symmetric encryption and decryption of the data
• Session closing and removing secrets
• Implement padding

• Print randomized PIN to the user
• Start and close a new session using the PIN
• Exchange protected data between the user PC and the Card
• Switch keys and IV of one way of encryption

• Finish the report
• Prepare the slides
• Submit slides to MUNI IS

Severity: critical
Risk: high/critical
Problem description: The application does not implement message integrity and replay checking and instead relies on encryption/decryption failing to detect message manipulation. While the fact that sessions are short and decryption is checked to mitigate the issue to some extent, it means that, for example, messages can be held from the card. We have successfully tired this with the functionality for storing data, where we can hold back the encrypted secret and simply report back that we have received the data properly as card (either by replaying the message a card sent previously or sending anything as only return code was checked here.
Additionally, as no message counters or unique data is included in every message, an attacker can observe traffic for identical messages, gaining additional knowledge about the communication.
Remediation: add message counter and hash to plaintext message with synchronization of counters and checking of hash on both ends. Example of new plaintext format: hash || counter || text.
Add these protections to plaintext so they cannot be easily modified.

Overall great work guys, really nice implementation

• Attend the meeting
• Present the Phase 3 results
• Receive dem points for our hard work
• Share a beer online, we deserved it

• Inspect the implementation
• List our findings
• Open issues in the target repository

• Generate EC keypairs on PC and Card
• Encode keys to ANSI X9.62 and exchange them
• Generate shared secret for PC and Card

Hello all,
your project caught my attention during final presentations, and I really like the work you guys did. I checked the presentation and report again because I was interested in some project which utilized automata-based programming for java cards. Your presentation seems like you implemented this approach. However, I cannot find OOP automata-based source code in your applet. I found the statusVar attribute, which can have a value of 0, 15, or 240. Is your FSM implemented with assigning and checking values of this attribute, or are there anywhere defined states with transitions and allowed actions?
Thanks!

• NXP JCOP 5.2
• RHEL 7.1
• ST33TPHF2E TPM 2.0

• Prepare the issues
• Write the text
• Write the selected vulnerabilities
• Finalize and export the report
• Submit to MUNI IS

• Generate final pdf file
• Submit report to the MUNI Information System

Severity: high - critical
Risk: high – high chance of affecting legitimate users and causing disruption of service
Problem description: The application incorrectly reads the PIN value entered by the user as a byte array and does not check the amount of data read. As a result, the data can be incorrectly parsed and further processed, resulting in either a) need for repeated authentication or b) multiple PIN attempts deducted as a part of one attempt, possibly blocking the card unintentionally.
Remediation: either check the amount of read data or read string and parse it to an integer.