# Threat Model Enumeration and discussion of known attacks which the Phonon ecosystem will need to prevent or significantly mitigate in protocol and implementation level ## Known Attacks Classify: C-I-A (Confidentiality, Integrity, Availability) ### Man in the Middle Attack An adversary is able to intercept communication packets at some point in between the two communicating phonon secure modules. They may either be able to capture these packets for later use or able to transparently modify and forward these packets on mid phonon exchange. This could be between a card and a user's local client or between two phonon clients. #### Man in the Middle Mitigation Secure end to end encryption between all endpoints in the system should prevent a man in the middle from being able to read, modify, or misuse any packet in the system ### Stolen Certificate Attack Attacker is able to extract a private identity key key from a card resulting in the ability to impersonate a legitimate phonon card without needing to follow the secure phonon module's rules. #### Stolen Certificate Mitigation Securely designed card firmware which protects the identity private key prevents software attacks to extract from a card. The hardware security guarantees of the card prevent or make economically infeasible physical attacks on the hardware attempting to reveal the private key material. Should a certificate be stolen despite these mitigations, revocation of the stolen cert upon detection can prevent further exploitation of the bad certificate. ### Fraudulent Certificate Attack (I) Attacker is able to obtain a Certificate Authority signature over an illegitimate private key, resulting in the ability to impersonate a legitimate phonon card without needing to follow the secure phonon module's rules. #### Fraudulent Certificate Mitigation A secure Certificate Authority certificate issuance process prevents the Certificate Authority from incorrectly issuing certificates. Cryptoeconomic guarantees managed by the Phonon DAO prevent insider threats or other attempts to circumvent the legitimate certificate issuance process. Should a certificate be fraudulently obtained despite these mitigations, revocation of the cert upon detection can prevent further exploitation of the bad certificate. ### Replay Attacks (I) Attacker is able to obtain and reuse a phonon transfer packet or other message to trick a card into repeating an operation that should only occur once. For instance, replaying a transfer to the same card after that card has already received a phonon transfer packet and sent it out again, thereby allowing for doublespending of the phonon. ### Replay Attack Mitigation Every packet transferred between phonon cards must include a counter or nonce which allows for recipient cards and clients to identify when a message is being replayed. ### Command Injection Attacks (I) An attacker maliciously crafts a packet and is able to send it to a phonon card or client and trick it to performing an unintended operation. ### Command Injection Mitigation A secure software implementation on both the card and client side prevents unintended operations from being carried out. ### Card Tear / Timing Attacks (I) An attacker physically disconnects a card or manipulates communication of a client to enact an unfair exchange of phonons between two sides. This can occur in cases of bidirectional phonon transfer, for example receiving change back for a payment. ### Mitigation Atomic operations within the exchange protocol which make it impossible to performt these attacks, or indeterminate operation of exchanges which make it infeasible to consistently execute these attacks with a financial gain. Outside of that, the normal social/legal consequences of thefts help prevent these attacks, as they are performed between the two counterparties participating in an exchange and easily detectable. ### DDoS / Griefing Attacks (I-A) An attacker sends a great number or a small number of particularly annoying packets to a phonon client or card in order to prevent it from being able to operate correctly. #### Mitigation Client side software protections against DDoS to enable client liveness, such as rate limiting requests from specific IPs or limiting accepted packets to a preapproved list. As well, requiring messages from other phonon participants to carry legitimate signatures when appropriate, can limit the transfer packets considered to those generated by legitimate phonon cards ### Credential Theft Attackers are able to compromise the authentication method to a phonon card, such as the PIN, and use it to execute unauthorized operations. #### Mitigation A secure authentication method and operation of the phonon card only with trusted clients.