73 lines
3.7 KiB
Markdown
73 lines
3.7 KiB
Markdown
# Table-top discussion
|
|
|
|
|
|
## Documentation and Tutorials
|
|
1. [Enrollment](https://git.infra.nkode.tech/dkelly/pynkode/src/branch/main/docs/enrollment_diagram.md)
|
|
2. [Login](https://git.infra.nkode.tech/dkelly/pynkode/src/branch/main/docs/login_diagram.md)
|
|
3. [Cipher and Renew](https://git.infra.nkode.tech/dkelly/pynkode/src/branch/main/docs/encipher_decipher_renew_nkode.md)
|
|
4. [nKode API Tutorial 1](https://git.infra.nkode.tech/dkelly/pynkode/src/branch/main/notebooks/Enrollment_Login_Renewal_Simplified.ipynb)
|
|
5. [nKode API Tutorial 2](https://git.infra.nkode.tech/dkelly/pynkode/src/branch/main/notebooks/Enrollment_Login_Renewal_Detailed.ipynb)
|
|
6. [Dispersion Tutorial](https://git.infra.nkode.tech/dkelly/pynkode/src/branch/main/notebooks/Dispersion.ipynb)
|
|
7. [Split Shuffle](https://git.infra.nkode.tech/dkelly/pynkode/src/branch/main/notebooks/Split_Shuffle.ipynb)
|
|
|
|
## Discussion Topics
|
|
### nKode Length
|
|
[Memorized Secret](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret) `Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric.`
|
|
- The minimum entropy for a randomly chosen memorized secret is approximately 20 bits.
|
|
- A keypad with 6 keys, each having 9 properties, exceeds this requirement with a minimum 4-character nKode, providing approximately 23 bits of entropy.
|
|
|
|
### nKode Observation
|
|
- Cracking an nKode [Evil nKode](https://git.infra.nkode.tech/dkelly/evilkode)
|
|
- Replay Attack
|
|
|
|
### Dispersion Attack
|
|
|
|
### nKode Over low-bandwidth
|
|
|
|
### nKode Over Unencrypted Channel
|
|
- TOTP
|
|
- DARC
|
|
|
|
### Discussion Outcomes:
|
|
|
|
#### Attacks and controls
|
|
| Attacks | Controls |
|
|
|-------------------------|--------------------------------------------------------------------------------|
|
|
| Screen Recording Attack | Split shuffle/more icons per key than keys |
|
|
| Exfiltrated DB | Physically separated keys and icons, partial or full encryption, nKode renewal |
|
|
| *APT | *Don't wait for garbage collector, manage timeouts |
|
|
| Phishing | Dispersion Resistant Keypad, nKode policy, passkey protected keypad icons |
|
|
| *MiTM | TLS, *TOTP shuffle, *DARC |
|
|
*not implemented yet/needs another look
|
|
|
|
#### asks for Dr. Kandah
|
|
|
|
- Evil nKode screen watching/key replay
|
|
- Can we rig the shuffle in our favor? How long do we need to cache?
|
|
- shoulder surfing
|
|
- Keylogger resistance
|
|
- split shuffle is unbiased
|
|
- Dispersion Attack/Phishing attack
|
|
- CAC/passkey protection for server stored icons
|
|
- is the dispersion algorithm unbiased?
|
|
- validate the cipher
|
|
- validate the server-side values
|
|
- validate the relationship between the mask and the hash
|
|
- validate the renewal
|
|
- are these processes secure?
|
|
- Minium amount of encryption needed
|
|
- Least encryption:brute force crack with plain text database breach
|
|
- Most encryption: everything is encrypted
|
|
- Is there an secure inbetween? what stays plain text what gets encrypted with HSM?
|
|
- How long does it take to brute-force with plain and what's gained?
|
|
- how often does nkode need to be changed if at all?
|
|
- if it does need to be changed can we roll the icons? can we start with 4 icons and add icons over time?
|
|
- Low-bandwidth: how low can we go?
|
|
- TCP vs UDP
|
|
- Security of RX/TX without tls/encrypted channel
|
|
- Hypothetical: Break the cipher keys onto different machines in different locations?
|
|
- TOTP shuffle on client and server
|
|
|
|
|
|
Other stuff:
|
|
- unbiased icons/psychology |