Migrate Markdown-Notes: projects, meetings, reference, personal
This commit is contained in:
62
projects/arcanum/NSF/Clarifying nKode v5.md
Normal file
62
projects/arcanum/NSF/Clarifying nKode v5.md
Normal file
@@ -0,0 +1,62 @@
|
||||
_Please clarify the specific new high-risk technical innovation you are proposing to develop, and explain how you will be able to create a defensible competitive advantage. Many systems of this general type have been studied in the past._
|
||||
|
||||
??? of 3,500 characters w/ spaces
|
||||
Proposed high-risk technical innovation:
|
||||
|
||||
nKode is an observation-resistant “something-you-know” authentication method that replaces direct entry of a static secret (a PIN or password). The user’s long-term secret is a short sequence of memorable attributes (for example four icons). At each authentication, the terminal displays a randomized layout to protect against key loggers and social engineering attacks, such as shoulder surfing, that groups many attributes into a small number of selectable keys. The user does not enter their secret attributes directly. Instead, they enter the key IDs that currently contain their secret attributes.
|
||||
Example:
|
||||
Secret attributes: 😍🤢🤐🥸
|
||||
|
||||
_key1_ _key2_
|
||||
|
||||
| 😃😍 | | 🥸🤩 |
|
||||
|
||||
| 😇😎 | | 🤓🥳 |
|
||||
|
||||
----- -----
|
||||
|
||||
_key3_ _key4_
|
||||
|
||||
| 🥺🤯 | | 🫥🤥 |
|
||||
|
||||
| 😡🥶 | | 🤢🤐 |
|
||||
|
||||
enter: 1,4,4,2
|
||||
|
||||
After authentication, the keypad is shuffled.
|
||||
|
||||
_key1_ _key2_
|
||||
|
||||
| 🫥😍 | | 🥸🤥 |
|
||||
|
||||
| 😇🤐 | | 🤢🥳 |
|
||||
|
||||
----- -----
|
||||
|
||||
_key3_ _key4_
|
||||
|
||||
| 😃🤯 | | 🥺🤩 |
|
||||
|
||||
| 😡😎 | | 🤓🥶 |
|
||||
|
||||
----- -----
|
||||
|
||||
enter: 1,2,1,1
|
||||
|
||||
The user experience remains “type four digits,” but the meaning of those digits changes each time based on the on-screen challenge.
|
||||
|
||||
Why this is materially different from prior studied approaches:
|
||||
|
||||
We recognize that observation-resistant PIN entry methods and graphical password families have been studied extensively. nKode differentiates on two practical dimensions that matter in PoS/ATM settings:
|
||||
|
||||
(a) Designed to remain resistant under multiple recorded observations (not just one). A common limitation of observation-resistant schemes is that they are designed to resist human observation not video or screen recordings. In contrast, based on our work with McCrary, we are targeting nKode configurations in which an attacker must record on the order of 5 or more sequential authentications of the same user’s nKode to recover the underlying secret. See our work on https://github.com/Arcanum-Technology/nkode-shuffle.
|
||||
|
||||
b ) nKode does not require the user to enter an exact passcode sequence. Consider a keypad with 10 keys, each key displaying 10 possible icons, that can be used in a 4 icon sequence. Across all possible configurations, a user's nKode is one of 100,000,000 distinct 4-icon sequences. However, in any single login attempt, the user’s correct response maps to one of only 10,000 possible key-entry sequences. No other system works like this.
|
||||
|
||||
Defensible competitive advantage:
|
||||
|
||||
Our defensible advantage is that our IP covers a family of nKode implementations, not a single keypad skin. The same mechanism can ship in regulated payment settings as a virtual keypad that mirrors physical keys, and in software and accessibility variants by grouping and reshuffling visual, alphanumeric, audio, or tactile attributes. Because the claims cover both the attribute types and the grouping mechanism that defines the challenge, a fast follower cannot avoid the core invention through cosmetic substitutions (for example, swapping emojis for letters/numbers).
|
||||
|
||||
Future Work:
|
||||
|
||||
nKode is not limited to PoS and ATMs. It can replace passwords in apps and websites by presenting unique AI-generated icons for each user. This eliminates password reuse, keyloggers, and dictionary attacks. These properties make it a strong candidate for healthcare (where authentication happens frequently on shared or semi-public workstations) and defense (where adversaries may capture keystrokes and recorded logins).
|
||||
Reference in New Issue
Block a user