Fraud w/Cred – Attack Vectors and Remediation's
Fraud w/Credential – Attack Vectors & Remediations
Thursday 11A
Convener: Daniel Hardman
Notes-taker(s): Daniel Hardman & Duane Johnson
Tags for the session - technology discussed/ideas considered:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
1. Notes received from Daniel Hardman:
We discussed what kinds of attacks are possible because of different conditions in issuance or verification with credentials. We grouped the attacks and produced a list of the remediations , and we agreed that we would continue the conversation through a spreadsheet. Click link to said spreadsheet to continue the conversation: https://docs.google.com/spreadsheets/d/1HALoNgZ7GTogw324squ7LRL4unfLSmPH_8B1ibxCQgE/edit
- ********************* ************************
2. Notes received from Duane Johnson:
Fraud with Creds:
- we need to have a collection of "well known" types of weaknesses under various credential scenarios, e.g. similar to the well-known "man-in-the-middle" attack that helps people think through security scenarios
- ZKP: Zero-Knowledge Proof
Types of Attacks:
- "zero context interaction": you only interact once, party you're talking to is "completely unknown" with regard to their credentials; when you're done interacting, you don't seee them again. Easy to impersonate. You think you have trust with encryption, etc., but you don't really have trust--no long-standing relationship.
- AAP: Agent Authorization Policy (which device is allowed to do proving--part of the proof includes requirement that you're doing the proof on a device that is authorized)
- "social engineering on credential holder":
- "invalid re-use": you've used the credential once, but then you show up and use it again when you weren't authorized to, or in a context that's different. e.g. "movie ticket"
- "poor issuing assurance": credential shouldn't have been authorized in the first place.
- "inadequate context for assertion": proof that I showed up at Bank of America (credential with my name on it), is not the same as a credential from Bank of America that my name is on the mortgage (but an outsider might be confused by the level of assurance the former provides about my name)
- "sybil attack on issuance": getting someone to issue multiple credentials of the same kind on you when they meant to only do it once
- "stolen cred"
- "cloning": copying private keys from one device to another
- "escalation": one level of credential being used to get permission to do more than was intended
- "invalid revocation": e.g. getting rid of someone's driver's license when it's perfectly valid; someone could use this for social engineering, posing as someone here to help get the credential back
- "reputation":
- "collusion": parties are actively trying to subvert system on an ongoing basis; e.g. selling credentials on the dark web, "the pirate bay" of credentials--selling ZKP proof along with credential. Suppose student is trying to apply to college--you want to prove your SAT scores are really high--someone wants to buy the credential that proves that.
- "poor cryptography on issuance":
- "staleness": e.g. taking advantage of the fact that I know more about current state of a blockchain than you
- "shared biometrics":
- "beer scenario": I'm 18 and I can buy beer for my 17 year old buddies
Mitigations:
- "invalid re-use": sample scenario: simultaneous use of a one-time ticket; sample scenario: voter fraud--you should be able to vote only one time in an election. Mitigation: (without ZKP:) unique identifier; (with ZKP:) link secret allows undisclosed unique identifier. Verifier/Relying Party is using the uniqueness of the identifier to ensure re-use constraints.
- "collusion": if we refresh often, i.e. "frequent re-issuance" can mitigate slow-moving black market. Indy wallets do not have "export private key" API.
Components Necessary for Use of Credentials
+----------------------+
| Creds | Keys |
+--------+-------------+
| AAP | Link Secret |
+--------+-------------+
* AAP = Agent Authorization Policy
