Migrate Markdown-Notes: projects, meetings, reference, personal
0
projects/arcanum/1.16.26 Tax Slayer.md
Normal file
@@ -0,0 +1,9 @@
|
||||
|
||||
Questions:
|
||||
- What's the scoring threshold?: There is no threshold
|
||||
|
||||
Hit on The Auburn name:
|
||||
I'm an ex Lockheed martin dev
|
||||
|
||||
|
||||
Explain what we need the money for and why darpa
|
||||
80
projects/arcanum/DARPA-ERIS/Advancing the SotA slides.md
Normal file
@@ -0,0 +1,80 @@
|
||||
## Slide 1: How nKode Addresses the Topic Area
|
||||
|
||||
- Topic Area: Advanced technologies for resilience, efficiency, and effectiveness in strategic systems
|
||||
- Focus: Critical infrastructure and military C2 systems (strategic, command, operational, tactical edges)
|
||||
- nKode's Fit: Enhances authentication resilience in contested/low-bandwidth environments
|
||||
- Benefits: Improves efficiency via intuitive, low-cognitive-load access; boosts effectiveness by preventing bypasses
|
||||
- Alignment: Supports Zero Trust, edge computing, and secure ops in dynamic conditions
|
||||
|
||||
**Speaker Notes:** This slide directly ties nKode to the ERIS topic area from the DARPA announcement, emphasizing improved resilience (e.g., credential reuse/keylogger immunity over unencrypted networks), efficiency (faster logins under stress without keyboards), and effectiveness (reduced errors, mission continuity for Tactical Assault Kits). It addresses vulnerabilities in C2 systems across edges, enabling information superiority against AI-driven threats like cognitive electronic warfare. This positions nKode as a breakthrough for national security, aligning with ERIS's goal of curating disruptive solutions for rapid acquisition.
|
||||
|
||||
## Slide 2: Contribution to DARPA's Mission
|
||||
|
||||
- DARPA Mission: Create technological surprise for U.S. national security
|
||||
- nKode's Role: Reinvents "something you know" authentication with keyboard-less, AI-generated icons
|
||||
- Surprise Element: credential reuse, and keylogger-immune; operable over unencrypted/low-bandwidth networks
|
||||
- Impact: Adversaries surprised by resilience against credential harvesting in contested environments
|
||||
- Benefit: Protects missions, lives, and infrastructure from AI-driven cyber threats
|
||||
|
||||
**Speaker Notes:** DARPA's mission, as stated in the ERIS announcement, is about technological surprise. nKode contributes by obsoleting text-based passwords, providing an asymmetric advantage in cyber-resilient warfare. For example, in tactical edges with limited bandwidth, it enables secure access to Tactical Assault Kits without traditional vulnerabilities. This aligns with ERIS goals of rapid acquisition for disruptive solutions, fostering information superiority against nation-state threats like cognitive electronic warfare.
|
||||
|
||||
## Slide 3: How the Problem is Addressed Today
|
||||
|
||||
- Current Methods: Long, complex passwords (12-16 characters) rotated every 60-90 days
|
||||
- Vulnerabilities: Prone to reuse, keyloggers, shoulder surfing; high cognitive load under stress
|
||||
- Limitations: Requires keyboards (impractical in tactical gear); needs secure channels for MFA
|
||||
- Issues: 95 hacks per second globally; bypass in high-risk environments
|
||||
- Alternatives: Biometrics (facial/iris/fingerprint) – fail in duress, dirt, or low light
|
||||
|
||||
**Speaker Notes:** Today, authentication relies on outdated standards per NIST/DoD, leading to credential reuse and exploitation. Passwords can be easily compromised via reuse, especially at the tactical edge where bandwidth is low and stress is high. Biometrics help but are constrained in field scenarios (e.g., gloves, environmental factors). This results in mission risks, as warfighters may bypass controls. nKode addresses these deficiencies head-on.
|
||||
|
||||
## Slide 4: What's New in nKode's Approach
|
||||
|
||||
- Novel Features: Shuffling icons on a patented virtual keypad; AI-generated unique icons per user
|
||||
- Comparisons to Current Practices:
|
||||
- Vs. Passwords: No text input; exceeds NIST entropy (1 in 8-24M guess rate for 4 icons)
|
||||
- Vs. Biometrics: No hardware dependency; works under pressure/duress
|
||||
- Backend: ChaCha20 CSPRNG for secure shuffling over unsecure networks
|
||||
- Resilience: Immune to keyloggers, replay attacks; auto-rotates without user action
|
||||
|
||||
**Speaker Notes:** What's new is the dynamic, visual paradigm: icons shuffle per login, mapped to tokenized values via backend cipher. Unlike static passwords or biometrics, nKode prevents reuse (unique icons) and operates in low-bandwidth environments. This compares favorably to current practices by flipping the usability-security trade-off – easier to remember yet more secure. It's TRL 5-validated, per our prior ERIS feedback, and advances SoTA by closing attack vectors like shoulder-surfing (6.5 observations needed to crack vs. 1).
|
||||
|
||||
## Slide 5: Unique Insights for Advancing SoTA
|
||||
|
||||
- Insight: Security must be intuitive to ensure adoption; visual memory outperforms text-based
|
||||
- Advancement: Reduces friction in MFA's "something you know" factor (unchanged since 1961)
|
||||
- Differentiation: Dispersion-resistant enrollment; attribute renewal for proactive defense
|
||||
- Why Transformative: Enables Zero Trust in contested edges; scales to commercial (banking/healthcare)
|
||||
- Evidence: Meets/exceeds DoD password standards while lowering errors
|
||||
|
||||
**Speaker Notes:** Our unique insight is that stronger security via ease-of-use leads to reliable adoption, improving mission outcomes. Humans recall images better than complex passwords, reducing cognitive load for warfighters. This advances SoTA by integrating AI icons with cryptographic primitives, resisting AI-driven attacks. Unlike current static inputs, nKode's randomized interface ensures no two logins map the same – a paradigm shift for resilience in strategic systems.
|
||||
|
||||
## Slide 6: Foreseen Barriers
|
||||
|
||||
- Adoption Risk: Authentication changes are high-risk; companies hesitant to be first adopters
|
||||
- Pitch History: Positive feedback from dozens (e.g., FIS, banks) over 10 years, but no implementations
|
||||
- Technical: Integration with legacy DoD systems; user training; device compatibility (rugged tablets)
|
||||
- Evolving Threats: Advanced AI shoulder-surfing; scaling icon generation
|
||||
- Mitigation: Leverage ERIS for rapid pathways; partner with McCrary Institute for validation
|
||||
|
||||
**Speaker Notes:** Barriers include institutional inertia – despite excitement from fintech like FIS (Fidelity National Information Services), no one wants to pioneer due to perceived risks. In DoD, integrating with C2 systems or ATACs could face hurdles. We'll address via human factors expertise (as per prior feedback) and field testing. Evolving threats like AI exploits require ongoing R&D, but nKode's design inherently resists them.
|
||||
|
||||
## Slide 7: Why nKode Will Succeed
|
||||
|
||||
- Market Validation: Independent survey by User Insight – 52% prefer nKode (vs. 28% passwords)
|
||||
- High Acceptance: 17% above "very high" benchmark (35%)
|
||||
- Team Strength: Veterans with cyber ops experience; TRL 5 proven
|
||||
- Dual-Use Potential: Defense (tactical edge) + Commercial
|
||||
- Evidence: Exceeds benchmarks; low friction deployment
|
||||
|
||||
**Speaker Notes:** Success is backed by data: User Insight's survey showed exceptional preference (52%), far above norms, indicating strong usability. Our team's expertise (Army/Navy vets) and partnerships ensure execution. nKode's success lies in its intuitive design – users remember one nKode for all, with auto-rotation. This will drive adoption, per ERIS goals, leading to safer operations.
|
||||
|
||||
## Slide 8: Proposed Plan/Strategy if Funded
|
||||
|
||||
- Phase 1: Adapt commercial app for tactical edge; integrate with ATACs/Tactical Assault Kits
|
||||
- Phase 2: Field validation/testing in simulated environments; address barriers (training/integration)
|
||||
- Phase 3: Advance to TRL 6-7; deploy OpenID Connect for DoD systems
|
||||
- Timeline: 12-18 months; focus on low-bandwidth resilience
|
||||
- Outcomes: Prototype for warfighters; pathway to commercialization
|
||||
|
||||
**Speaker Notes:** If funded, we'll pivot our existing commercial app (with OpenID/OAuth support) to defense needs. Develop a glove-friendly version for tactical edges, sans biometrics. Strategy: Collaborate with McCrary/Forge Institutes for demos and integration. Budget for AI enhancements and testing. This aligns with ERIS's rapid acquisition, transitioning from idea to prototype for enhanced strategic system resilience.
|
||||
57
projects/arcanum/DARPA-ERIS/DARPA ERIS Feedback 12-17-25.md
Normal file
@@ -0,0 +1,57 @@
|
||||
Defining the Problem & Current State of the Art
|
||||
|
||||
Evaluator 1: Superior out of Superior "The submission addresses the challenge of reliable and secure user authentication in denied or sophisticated threat environments, particularly on edge devices. Current state-of-the-art capabilities and regrets are clearly identified."
|
||||
|
||||
Evaluator 2: Superior out of Superior "The submission does an excellent job of describing the problem of authentication - especially is use cases involving edge4 devices under stressful conditions. The submission further does a very nice job describing the state-of-the art, i.e. passwords and biometric, and highlighting the challenges associated with these approaches."
|
||||
|
||||
Evaluator 3: Highly Satisfactory out of Superior "Summary: Current password approaches to system security presents vulnerabilities Strengths: - Traditional “passwords” are recognized as being prone to hacking and abuse. This is particularly the case where “strong” passwords are not enforced. - “Lazy” users frequently re-use passwords across many sites. - Password expiration creates a burden on users to update and memorize frequent changes to many protected sites, making. Areas to improve: - Many approaches to include random generation of “strong” passwords tied to personal user credentials, dual/multi-factor authentication, biometrics and tokens/CAC cards have helped mitigate traditional PW risks. - The significance of specific tactical (or strategic) system vulnerabilities to AI-orchestrated cyberattacks or other threats was only generally addressed.
|
||||
|
||||
|
||||
|
||||
Advancing the State of the Art
|
||||
|
||||
Evaluator 1: Satisfactory out of Superior "The submission presents a solution to advance the state-of-the-art of authentication by employing a pictograph-based system that is encrypted using an industry-standard stream cypher (ChaCha20). The presented system has several attractive features that simplify reliable authentication in the field, where there are challenges with standard biometric techniques. The white space chart clearly indicates the presented system’s capability benefits compared to legacy password approaches. The submission, **however, does not present any technology development of the system beyond scaling up the number of icons, so there is no apparent DARPA role."**
|
||||
|
||||
Evaluator 2: Marginal out of Superior "I struggled with this rating because I think the submission presents an innovative solution to the authentication problem, I just think DARPA may not be the right customer given where they are in the development cycle. It looks like the technology is largely developed - **the submission does not do a good job of describing the technical challenges DARPA funding will help them overcome, beyond adapting it for tactical edge devices and integration."**
|
||||
|
||||
Evaluator 3: Satisfactory out of Superior "Summary: The submission advocates for a new paradigm for user authentication that is “more secure, intuitive and scalable” than traditional passwords.
|
||||
Strengths:
|
||||
- Innovative approach to site protection using AI
|
||||
- generated icons making “passwords” easier to remember, even across many different applications and domains and preventing PW re-use.
|
||||
- The visual UI is patented and customizable, with development customized based on operational feedback from fintech, defense and cybersecurity.
|
||||
- The submission suggest alignment to ESIR’s topic area for advanced technologies for improved resilience, efficiency and effectiveness of strategic systems.
|
||||
**Areas to improve:**
|
||||
- The submission suggests that biometrics are inferior to the presented technology but often provides highly effective authentication in tactical and other environments.
|
||||
- The technology is indicated to be TRL 5, with the greatest risks to adoption being integration, training, and “evolving AI threats”. These could be addressed as DOTMLPF gaps verses a need additional transformative research.
|
||||
- Research goals of the submission lack definition and are generally focused on field trials verses discovery.
|
||||
|
||||
|
||||
|
||||
Team Capability (Key Personnel Vision, Expertise, and Experience)
|
||||
|
||||
Evaluator 1: Superior out of Superior "A very capable project team includes university cyber center personnel, professors with expertise in mathematics and computer science, and members with military experience. The team has already developed and successfully demonstrated a prototype product."
|
||||
|
||||
Evaluator 2: Superior out of Superior "The presented team has excellent credentials covering all the relevant expertise required to make the solution a reality - cybersecurity, math, software, operational expertise, etc."
|
||||
|
||||
Evaluator 3: Highly Satisfactory out of Superior "Summary: The submitter is a small business affiliated with two not-for-profits focused on cybersecurity. Strengths: - The team has already developed the technology and has IP protection for it. - Partnership provide additional depth of expertise and infrastructure to support development. - The submitting team is indicated to have substantial expertise and experience in cybersecurity, intelligence operations, red teaming, mathematical frameworks, and software development. Areas to improve: - Additional expertise or partnerships with military end-users that would support trials of the technology would strengthen the submission. - Project vision is not indicated.
|
||||
|
||||
|
||||
|
||||
Defense and/or Commercial Market Use Case/Impact
|
||||
|
||||
Evaluator 1: Highly Satisfactory out of Superior "The simplified and robust authentication process would improve user experience and enhance security for military users in a denied or cyber-threat environment."
|
||||
|
||||
Evaluator 2: Highly Satisfactory out of Superior "I can imagine a wide variety of military and commercial use cases where this technology would be be very beneficial, especially in a contested environment with operators under stress. The main reason I did not rate as superior is because I am concerned there might be some military applications where it would be difficult to see the small pictograph icons."
|
||||
|
||||
Evaluator 3: Highly Satisfactory out of Superior "Summary: The submission indicates broad applicability for the solution, to include tactical edge authentication and any commercial application where traditional PW authentication is employed. Strengths: - A range of defense use cases are indicated including tactical edge authentication, focused on the TAK application. - Commercial applications are suggested to be vast, with healthcare and banking as two exemplars. - Application of the solution of have the impact of more secure systems that are easier for end-users to access. Areas to improve: - None noted.
|
||||
|
||||
|
||||
## Coaches Feedback (Mike Cooper)
|
||||
|
||||
- make the demo at the end bigger. push it forward to advancing the state of the art
|
||||
- testomonials go a long way (go and ask soldiers what they'd use). maybe emphasize User Insight. Discuss operational gap with biometrics
|
||||
- they don't know what we're going to do with the money. (should borrow from NSF)
|
||||
- add a slide that says "advancing the state of the art?"
|
||||
- we'll likely get 2 of the three evaluators
|
||||
- make sure we are at a 4 but not above. say we're going to take their money and get us to a TRL 6
|
||||
- Don't be afraid be technical
|
||||
3
projects/arcanum/DARPA-ERIS/DARPA ERIS Feedback.md
Normal file
@@ -0,0 +1,3 @@
|
||||
DoD specific usecase: gas mask, face mask,
|
||||
- Need to mark as a resubmission, it's in a drop down menu
|
||||
-
|
||||
20
projects/arcanum/DARPA-ERIS/DARPA ERIS Team.md
Normal file
@@ -0,0 +1,20 @@
|
||||
The nKode project team is a unified collaboration between Arcanum Technology LLC and Auburn University’s McCrary Institute for Cyber and Critical Infrastructure Security, blending Arcanum's proprietary innovation with McCrary's elite cybersecurity, intelligence, and computational expertise.
|
||||
|
||||
Brooks Brown, as the inventor and Co-founder of nKode, provides the foundational vision and architectural expertise essential for driving this innovative authentication solution forward. His role as Chief Development Architect positions him uniquely to guide the project's technical direction.
|
||||
|
||||
Donovan Kelly, with over seven years of software development experience across defense, healthcare, media, and authentication sectors, including prior work as a Space Ground Software Engineer at Lockheed Martin, is ideally suited to lead the technical implementation of nKode. As CTO of Arcanum Technology LLC, he is actively developing nKode as a cutting-edge multi-factor authentication (MFA) system.
|
||||
|
||||
Dr. Craig Whittinghill serves as the Deputy Director for Applied Research and Services at the McCrary Institute. As a Navy Veteran with 29 years of service as a Naval Intelligence Officer, he brings extensive leadership in high-stakes cyber and intelligence operations.
|
||||
|
||||
Jonathan Sherk is a Principal Cybersecurity Research Engineer at Auburn University’s McCrary Institute. He leads a USDA grant on rural cybersecurity and co-leads Alabama’s State and Local Cybersecurity Grant Program. As an NSA-certified, CYBERCOM-accredited Red Team Lead, he has performed adversarial assessments on EUDs and Army products at the Threat Systems Management Office. His military service includes Army Special Operations in the 112th Signal Battalion and 7th Special Forces Group
|
||||
|
||||
Dr. Luke Oeding, an Associate Professor in the Department of Mathematics and Statistics at Auburn University, contributes advanced algebraic and computational expertise critical for nKode's underlying mathematical frameworks. His research focuses on applications of algebraic geometry and representation theory to tensors, quantum information processing, signal processing, and collaborative navigation.
|
||||
|
||||
Dr. Farah Kandah, an IEEE Senior Member and Associate Professor in the Department of Computer Science and Software Engineering at Auburn University, as well as a faculty affiliate with the McCrary Institute, provides specialized knowledge in cybersecurity, networking, and emerging technologies like IoT and quantum credentials. His research encompasses distributed computing, computer security and reliability, computer communications (networks), trust management in wireless mesh networks, and more.
|
||||
|
||||
- **Brooks Brown**: Chief Development Architect and Co-founder at Arcanum Technology, inventor of nKode.
|
||||
- **Donovan Kelly**: Chief Technology Officer at Arcanum Technology.
|
||||
- **Dr. Craig Whittinghill**: Deputy Director for Applied Research and Services at McCrary Institute.
|
||||
- **Jonathan Sherk**: Principal Cybersecurity Research Engineer at McCrary Institute.
|
||||
- **Dr. Luke Oeding**: Associate Professor in Mathematics and Statistics at Auburn University.
|
||||
- **Dr. Farah Kandah**: Associate Professor in Computer Science and Software Engineering at Auburn University, faculty affiliate at McCrary Institute.
|
||||
29
projects/arcanum/DARPA-ERIS/DARPA ERIS nKode Solution.md
Normal file
@@ -0,0 +1,29 @@
|
||||
|
||||
Submission Title (less than 128 characters)
|
||||
Abstract description (1,500 Characters)
|
||||
|
||||
Topic Area: Developing advanced technologies for improved resilience, efficiency, and effectiveness of strategic systems. This topic area supports technologies for critical infrastructure and military command-and-control systems (networks and applications across strategic, command, operational, and tactical edges).
|
||||
|
||||
Advancing the state of the art.
|
||||
Detail why the proposed solution is likely to advance the current state of the art within the solution's relevant field(s). DARPA’s mission is to create technological surprise for United States national security;
|
||||
|
||||
How does your solution contribute to that mission?
|
||||
nKode reinvents "something you know" authentication (unchanged since 1961) with a keyboard-less, AI-generated icon system that's phishing-resistant, keylogger-immune, and operable over unencrypted/low-bandwidth networks. Adversaries relying on traditional cyber exploits (e.g., credential harvesting) would be "surprised" by its resilience in contested environments.
|
||||
|
||||
How is the problem being addressed today?
|
||||
Long complex passwords changed every 60-90 days. password can
|
||||
|
||||
What is "new" within your approach as it compares to current practices and describe your unique new insight for advancing the state of the art?
|
||||
Shuffling icons on a virtual keypad.
|
||||
|
||||
What barriers do you foresee when attempting to advance the state of the art?
|
||||
Authentication is a difficult technology to change. Arcanum has been pitching nKode to fintech/banks for almost 10 years. Most potential clients want to use nKode. We've had positive feedback, even excitement, from dozens of company (FIS, ...). However nobody wants to be the first to implement it. Despite all the problems we can solve by replacing passwords and PINs, the risk is to high for most companies to be the first to try the technology.
|
||||
|
||||
What is new in your approach and why do you think it will be successful?
|
||||
We've conducted an independent market acceptance, through User Insight, to see if users would want to use nKode. We were told by the survey team that 35% accepts was a very high score. nKode was preferred by 52% (17% over what's considered high score) of participants over 28% who preferred passcodes and 19% with no preference.
|
||||
|
||||
Briefly state your proposed plan/strategy if funded.
|
||||
We've developed an nKode application that is geared toward commercial partners. We've developed and deployed OpenID connect applications (nKode as an Identity provider).
|
||||
We want to develop an application for warfighters at the tactical edge. An application that allows them to easily authenticate with gloves and without biometric authentication, just an ATAC.
|
||||
|
||||
|
||||
BIN
projects/arcanum/DARPA-ERIS/ERIS_Slide_v2.pptx
Normal file
1
projects/arcanum/DARPA-ERIS/ERIS_low_bandwidth.md
Normal file
@@ -0,0 +1 @@
|
||||
# ERIS Low Bandwidth
|
||||
24
projects/arcanum/DARPA-ERIS/Speakers notes.md
Normal file
@@ -0,0 +1,24 @@
|
||||
|
||||
Hello, My name is Donovan Kelly, CTO at Arcanum Technologies. We've developed nKode, a patented pictographic passcode that reinvents authentication—making it more secure and intuitive for tactical edge environments. Arcanum has partnered with the McCrary Institute at Auburn University to leverage their cybersecurity expertise and veteran insights.
|
||||
|
||||
Since their introduction in 1961 with MIT's Compatible Time-Sharing System, passwords have remained the cornerstone of "something you know" authentication. Yet, amid the rapid escalation of cyber threats over the ensuing six decades, this paradigm has undergone little fundamental reinvention. Passwords impose a taxing cognitive burden on warfighters, necessitating the memorization and periodic rotation of 12-16 character sequences every 60-90 days—a process prone to reuse across systems and errors amid high-stress operations. Their vulnerabilities are profound, with breaches occurring at a staggering rate of 95 per second worldwide, rendering them highly susceptible to credential harvesting. At the tactical edge, these deficiencies are amplified by environmental constraints. Inputting credentials while encumbered by tactical gear, such as gloves, proves impractical and often leads to security bypasses in high-risk, low-bandwidth scenarios that also constrain multi-factor authentication. Compounding this, AI-orchestrated attacks from nation-state actors intensify the overall threat landscape, underscoring the urgent need for evolution.
|
||||
|
||||
The state of the art includes static text inputs and biometrics like facial recognition or fingerprints, which work well in controlled environments but falter in real-world tactical scenarios—think low light for iris scans, noise for voice, or gloves blocking fingerprints. Systems like Software-Defined Radios and Tactical Assault Kits integrate Zero Trust and edge computing for better security, but they still rely on vulnerable authentication methods that AI exploits, cognitive electronic warfare, and signals intelligence can crack. This is where nKode steps in—addressing these gaps by advancing beyond static, text-based systems to a visual, resilient alternative.
|
||||
|
||||
nKode aligns with ERIS Topic Area “advanced technologies for improved resilience, efficiency, and effectiveness of strategic systems,” including critical infrastructure and military C2 across all edges. In real-world degraded comms where passwords, OTPs, or push prompts fail or are vulnerable, nKode strengthens authentication with keyboard-less icon challenges that move over tiny or even unencrypted pipes while staying resistant to capture and replay. This yields quick, low-cognitive-load logins under stress and reduces workarounds, keeping tools like Tactical Assault Kits online. The approach supports DARPA’s goal of technological surprise by denying adversaries easy wins from phishing and keylogging and by staying operable when bandwidth and trust are scarce.
|
||||
|
||||
Today, authentication relies on outdated standards, leading to credential reuse and exploitation. Passwords can be easily compromised via reuse, especially at the tactical edge where bandwidth is low and stress is high. Biometrics help but are constrained in field scenarios (e.g., gloves, environmental factors). This results in mission risks, as warfighters may bypass controls. What's new is the dynamic, visual paradigm: icons shuffle per login, mapped to tokenized values via backend cipher. Unlike static passwords or biometrics, nKode prevents reuse (unique icons) and operates in low-bandwidth environments. This compares favorably to current practices by flipping the usability-security trade-off – easier to remember yet more secure. It's TRL 5, and advances SoTA by closing attack vectors like shoulder-surfing.
|
||||
|
||||
|
||||
Our unique insight is that stronger security via ease-of-use leads to reliable adoption, improving mission outcomes. Humans recall images better than complex passwords, reducing cognitive load for warfighters. This advances SoTA by integrating AI icons with cryptographic primitives, resisting AI-driven attacks. Unlike current static inputs, nKode's randomized interface ensures no two logins map the same – a paradigm shift for resilience in strategic systems.
|
||||
|
||||
Barriers include institutional inertia—despite excitement from fintech like FIS (Fidelity National Information Services), no one wants to pioneer due to perceived risks. In DoD, integrating with C2 systems or ATACs could face hurdles. Scaling icon generation is key: we need millions or billions of AI-generated icons that are unique and psychologically neutral (free of biases that could make selections predictable), ensuring no AI can train on patterns for attacks. We'll address this via human factors expertise (as per prior feedback), field testing, and ongoing R&D—nKode's design inherently resists many exploits, but this requires advanced AI safeguards.
|
||||
|
||||
Success is backed by data: User Insight's survey showed exceptional preference (52%), far above norms, indicating strong usability. Our team's expertise (Army/Navy vets) and partnerships ensure execution. nKode's success lies in its intuitive design – users remember one nKode for all, with auto-rotation. This will drive adoption, per ERIS goals, leading to safer operations.
|
||||
|
||||
If funded, we'll pivot our existing commercial app (with OpenID/OAuth support) to defense needs. Develop a glove-friendly version for tactical edges, sans biometrics. Strategy: Collaborate with McCrary for demos and integration. Budget for AI enhancements and testing. This aligns with ERIS's rapid acquisition, transitioning from idea to prototype for enhanced strategic system resilience.
|
||||
|
||||
The nKode team is a unified collaboration between Arcanum Technology LLC and Auburn University’s McCrary Institute for Cyber and Critical Infrastructure Security. Brooks Brown, as the inventor and Co-founder of nKode, provides the foundational vision and architectural expertise essential for driving this innovative authentication solution forward. His role as Chief Development Architect positions him uniquely to guide the project's technical direction. Dr. Craig Whittinghill serves as the Deputy Director for Applied Research and Services at the McCrary Institute. As a Navy Veteran with 29 years of service as a Naval Intelligence Officer, he brings extensive leadership in high-stakes cyber and intelligence operations. Jonathan Sherk is a Principal Cybersecurity Research Engineer at Auburn University’s McCrary Institute. He leads a USDA grant on rural cybersecurity and co-leads Alabama’s State and Local Cybersecurity Grant Program. As an NSA-certified, CYBERCOM-accredited Red Team Lead, he has performed adversarial assessments on EUDs and Army products at the Threat Systems Management Office. Dr. Luke Oeding, an Associate Professor in the Department of Mathematics and Statistics at Auburn University, contributes advanced algebraic and computational expertise critical for nKode's underlying mathematical frameworks. His research focuses on applications of algebraic geometry and representation theory to tensors, quantum information processing, signal processing, and collaborative navigation. Dr. Farah Kandah, an IEEE Senior Member and Associate Professor in the Department of Computer Science and Software Engineering at Auburn University, as well as a faculty affiliate with the McCrary Institute, provides specialized knowledge in cybersecurity, networking, and emerging technologies like IoT and quantum credentials. His research encompasses distributed computing, computer security and reliability, computer communications (networks), and more. Lastly me. I have over seven years of software development experience across defense, healthcare, media, and authentication sectors, including prior work as a Space Ground Software Engineer at Lockheed Martin. In my current role as CTO of Arcanum Technology LLC, I am actively developing new ways to apply nKode to a variety of authentication problems.
|
||||
|
||||
|
||||
nKode offers significant impact in both defense and commercial markets, emphasizing the "so what" through practical applications and outcomes. In defense, nKode targets tactical edge challenges where current systems (e.g., passwords/biometrics) falter in DDIL scenarios (Denied, Disrupted, Intermittent, and Limited bandwidth/comms): Warfighters authenticate to secure comms or field kits via intuitive icons, resilient without full encryption, reducing bypass risks and improving continuity amid nation-state threats like signals intelligence. The impact? Stronger defenses, mission success, and warfighter safety. Commercially, it addresses massive markets: Replaces vulnerable passwords in banking (reducing phishing losses) or healthcare (securing patient data), with dual-use for infrastructure like utilities. The "so what": nKode closes usability-security gaps, potentially mitigating the $10.5T in annual global cybercrime costs by 2025, while enabling Zero Trust across sectors. If funded, we'll validate these via DoD pilots and commercial integrations for rapid transition.
|
||||
282
projects/arcanum/DARPA-ERIS/darpa_eris_slides.md
Normal file
@@ -0,0 +1,282 @@
|
||||
---
|
||||
marp: true
|
||||
theme: default
|
||||
paginate: true
|
||||
---
|
||||
<style>
|
||||
:root { --accent: rgb(218,104,66); }
|
||||
section {
|
||||
background: #fff;
|
||||
color: #000;
|
||||
font-size: 24px;
|
||||
line-height: 1.35;
|
||||
padding: 64px;
|
||||
}
|
||||
h1, h2, h3 { color: #000; margin: 0 0 .6em 0; }
|
||||
strong, b { color: var(--accent); font-weight: 700; }
|
||||
mark { background: color-mix(in srgb, var(--accent) 18%, white); color: var(--accent); padding: 0 .2em; border-radius: .2em; }
|
||||
a { color: #000; text-decoration: underline; text-decoration-color: var(--accent); text-underline-offset: 2px; }
|
||||
ul { margin: .6em 0 .6em 1.2em; }
|
||||
li { margin: .25em 0; }
|
||||
blockquote { color: #000; border-left: 4px solid var(--accent); padding-left: .8em; }
|
||||
code, pre { background: #f7f7f7; color: #000; }
|
||||
hr.rule { border: 0; height: 2px; background: #000; margin: 24px 0; }
|
||||
|
||||
/* Title slide layout */
|
||||
.title-wrap {
|
||||
display: grid;
|
||||
grid-template-columns: 1fr auto 1fr;
|
||||
align-items: center;
|
||||
gap: 24px;
|
||||
}
|
||||
.logo {
|
||||
max-height: 250px;
|
||||
object-fit: contain;
|
||||
}
|
||||
.nkode-title {
|
||||
font-size: 96px;
|
||||
letter-spacing: .5px;
|
||||
color: var(--accent);
|
||||
margin: 24px 0 8px 0;
|
||||
font-weight: 800;
|
||||
}
|
||||
.subtitle { font-size: 28px; margin-top: 0; }
|
||||
|
||||
/* Team grid */
|
||||
.team-grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(3, 1fr);
|
||||
gap: 18px 24px;
|
||||
align-items: start;
|
||||
}
|
||||
.person {
|
||||
display: grid;
|
||||
grid-template-rows: auto auto auto;
|
||||
gap: 5px;
|
||||
}
|
||||
.person img {
|
||||
width: 40%;
|
||||
aspect-ratio: 3/4;
|
||||
object-fit: cover;
|
||||
border: 2px solid #000;
|
||||
border-radius: 6px;
|
||||
}
|
||||
.person .name { font-size: 18px; font-weight: 700; color: var(--accent); }
|
||||
.person .role { font-size: 16px; color: #000; }
|
||||
.caption { font-size: 14px; color: #000; opacity: .85; }
|
||||
</style>
|
||||
|
||||
<div class="title-wrap">
|
||||
<img class="logo" src="./eris_imgs/arcanum-logo.png" alt="Arcanum Technologies Logo">
|
||||
<div></div>
|
||||
<img class="logo" src="./eris_imgs/mccrary-logo.jpg" alt="McCrary Institute Logo">
|
||||
</div>
|
||||
|
||||
<div class="nkode-title">nKode</div>
|
||||
<p class="subtitle">Pictographic passcodes for resilient authentication at the edge</p>
|
||||
<hr class="rule">
|
||||
<p><strong>Arcanum Technologies</strong> + Auburn University’s <strong>McCrary Institute</strong></p>
|
||||
|
||||
<!--Speaker Notes: Title
|
||||
Hello, My name is Donovan Kelly, CTO at Arcanum Technologies. We've developed nKode, a patented pictographic passcode that reinvents authentication, making it more secure and intuitive for tactical edge environments. Arcanum has collaborated with Auburn University McCrary Institute to leverage their cybersecurity expertise and veteran insights.
|
||||
-->
|
||||
|
||||
---
|
||||
# Defining the Problem
|
||||
|
||||
- **Historical Context**
|
||||
- Passwords as cornerstone of "something you know" authentication since 1961 (MIT's Compatible Time-Sharing System)
|
||||
- No major reinvention in over 60 years, despite evolving threats
|
||||
- **Key Problems in Authentication**
|
||||
- High cognitive load: 12-16 character passwords rotated every 60-90 days; prone to reuse and errors under stress
|
||||
- Vulnerabilities: Hacked at 95 per second globally; susceptible to phishing, keyloggers, and credential harvesting
|
||||
- **Tactical Edge Challenges:** Difficult with tactical gear (e.g., gloves); bypassed in high-risk, low-bandwidth environments; limits multi-factor authentication (MFA)
|
||||
|
||||
<!-- Speakers Notes: Defining the Problem
|
||||
Since their introduction in 1961 with MIT's Compatible Time-Sharing System, passwords have remained the cornerstone of "something you know" authentication. For warfighters, they impose a high cognitive and operational burden: memorizing and rotating 12–16 character strings every 60–90 days, often leading to reuse and mistakes under stress. Meanwhile, passwords are under constant attack, making them easy targets for credential harvesting. These weaknesses are amplified at the tactical edge, where gloves and gear make credential entry impractical and low-bandwidth, high-risk conditions limit conventional MFA—driving workarounds and security bypasses.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Current State-of-the-Art
|
||||
|
||||
- **Relies on static inputs:** Keyboards, text-based passwords
|
||||
- **Biometrics (facial/iris/fingerprint/voice):** Effective in ideal conditions but constrained in low-light, noisy, or gloved scenarios
|
||||
- **Current Tech:** Zero Trust, edge computing, AI-driven security in systems like Tactical Assault Kits, but compromised by AI attacks, signals intelligence, and nation-state exploits
|
||||
|
||||
<!-- Speakers Notes: Current State-of-the-Art
|
||||
The state of the art relies on static text inputs and biometrics like facial recognition and fingerprints. These can work in controlled settings, but in tactical edge conditions—noise, degraded visual environments, motion, low light, or gloves—biometrics’ probabilistic nature drives high failure rates. Meanwhile, Zero Trust, edge computing, and AI-driven security (e.g., Tactical Assault Kits) are advancing, yet remain vulnerable to AI-enabled attacks, signals intelligence, and nation-state exploitation.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<style scoped>
|
||||
section { font-size: 20px; }
|
||||
</style>
|
||||
|
||||
# nKode Advances the State-of-the-Art
|
||||
|
||||
- **What’s New in nKode’s Approach**
|
||||
- Patented virtual keypad with shuffling icons; AI-generated, user-unique icon sets
|
||||
- **Vs. Passwords:** No text entry; strong guessing resistance with compact inputs
|
||||
- Zero-trust architectures leveraging ChaCha20 to drive shuffling and OPAQUE (aPAKE) for mutual authentication over low-trust links
|
||||
- Resilient to keyloggers and replay; auto-rotation without user action; shoulder-surf resistant
|
||||
- **Why It Matters at the Edge**
|
||||
- Works in low-bandwidth or contested environments
|
||||
- Cuts cognitive load and speeds access, reducing bypass behavior
|
||||
- Preserves mission continuity for edge tools and C2 workflows
|
||||
|
||||
<!-- Speakers Notes: nKode Advances the State-of-the-Art
|
||||
nKode's dynamic, visual paradigm changes “something you know” authentication.
|
||||
Instead of typed secrets, the user authenticates through a patented virtual keypad whose icons shuffle every session.
|
||||
Each user gets a unique AI-generated icon set, and selections map to encrypted backend tokens—making offline guessing computationally infeasible and credential stuffing impossible.
|
||||
Under the hood, we use a zero-trust approach: ChaCha20 drives the deterministic shuffling of the keypad, and OPAQUE, an asymmetric Passcode Authenticated Key Exchange provides mutual authentication over low-trust links.
|
||||
This flips the usability-security trade-off because it's easier to remember and more secure than a password.
|
||||
-->
|
||||
---
|
||||
# How nKode Aligns with DARPA ERIS
|
||||
|
||||
- **Topic area fit:** Advances resilience, efficiency, and effectiveness for strategic systems across critical infrastructure and military C2 at strategic, command, operational, and tactical edges.
|
||||
- **Mission tie:** Supports DARPA’s aim to create technological surprise for U.S. national security.
|
||||
- **nKode’s role:** Reinvents “something you know” with keyboard-less, AI-generated icons to keep auth working in contested or low-bandwidth networks.
|
||||
- **Surprise element:** Resilient to credential reuse and keyloggers; can operate over unencrypted or bandwidth-constrained links without exposing secrets.
|
||||
- **Operational benefits:** Faster, low-cognitive-load access under stress; reduces bypasses and maintains mission continuity for edge tools like TAK.
|
||||
- **Architectural alignment:** Zero Trust, edge computing, and secure operations in dynamic, degraded conditions.
|
||||
- **Impact:** Hardens C2 and critical infrastructure against AI-driven credential harvesting and disruption in contested environments.
|
||||
|
||||
<!-- Speakers Notes: How nKode Aligns with DARPA ERIS
|
||||
nKode aligns with ERIS Topic Area “advanced technologies for improved resilience, efficiency, and effectiveness of strategic systems,” including critical infrastructure and military Command and Control. In real-world degraded comms where passwords, OTPs, or push prompts fail or are vulnerable, nKode strengthens authentication with zero-trust and keyboard-less icon challenges that move over low-bandwidth pipes while staying resistant to capture and replay. This yields quick, low-cognitive-load logins under stress. The approach supports DARPA’s goal of technological surprise by denying adversaries easy wins from phishing and keylogging.
|
||||
-->
|
||||
|
||||
<!--
|
||||
DEMO
|
||||
-->
|
||||
|
||||
---
|
||||
# Why nKode Will Succeed
|
||||
|
||||
- **Pitch History:** Winner of the FIS VC and Venturetech Pitch competitions
|
||||
- **Technical:** Integration with legacy DoD systems; user training; device compatibility (rugged tablets)
|
||||
- **Evolving Threats:** Advanced AI shoulder-surfing; scaling to millions/billions of unique, psychologically neutral icons to prevent AI prediction of user selections
|
||||
- **Mitigation:** Leverage ERIS for rapid pathways; partner with McCrary Institute for validation
|
||||
- **Market Validation:** Independent survey by User Insight – 62% prefer nKode (vs. 23% passwords)
|
||||
- **Team Strength:** Veterans with cyber ops experience; TRL 4
|
||||
- **Dual-Use Potential:** Defense (tactical edge) + Commercial
|
||||
- **Evidence:** Exceeds benchmarks; low friction deployment
|
||||
|
||||
<!-- Speakers Notes: Why nKode Will Succeed
|
||||
Institutional inertia is one of our biggest challenges.
|
||||
We've had interest from Fortune 500 fintech companies like FIS.
|
||||
However, authentication is a risky technology to change and nobody wants to be the first to do it.
|
||||
nKode has a great chance of succeeding.
|
||||
We've had a market acceptance study conducted by User Insight.
|
||||
A 35% favorability score is considered a high score for a new product.
|
||||
nKode was favored by 62% of participants.
|
||||
This is an exceptionally high favorability rating.
|
||||
That underscores just how needed a password alternative is.
|
||||
-->
|
||||
---
|
||||
# Proposed Plan/Strategy if Funded
|
||||
|
||||
- **Target:** TRL 4 → TRL 6 (operationally relevant prototype)
|
||||
- **De-risking milestone 1 — independent validation:** Obtain an **independent, implementation-agnostic** review of the system’s **zero-trust architecture**, including threat model, assumptions, and security claims.
|
||||
- **De-risking milestone 2 — implementation testing:** Conduct **penetration testing / red-teaming** of the prototype to uncover practical vulnerabilities and harden the deployed system under tactical-edge constraints (low bandwidth, intermittent connectivity).
|
||||
- **De-risking milestone 3 — scale enabler:** Deliver a repeatable pipeline capable of producing **millions to billions** of **psychologically neutral** icons to support scale without introducing bias.
|
||||
- **Result:** A validated design and hardened, scalable prototype ready for operationally relevant evaluation.
|
||||
<!-- Speakers Notes: Proposed Plan/Strategy if Funded
|
||||
If we are awardable, our goal is to move from TRL 4 to TRL 6 by building an operationally relevant prototype.
|
||||
First, we will commission an independent, implementation-agnostic validation of the zero-trust architecture—confirming the threat model, key assumptions, and security claims separate from any particular prototype build.
|
||||
Second, we will perform implementation-focused security assessment (penetration testing / red-teaming) of the prototype in realistic tactical-edge conditions, including low bandwidth and intermittent connectivity, to identify exploitable weaknesses, harden the system, and document residual risk.
|
||||
Third, we will deliver a scalable, repeatable pipeline to generate millions to billions of psychologically neutral icons so the system can scale without introducing biasing or emotionally “loaded” imagery.
|
||||
-->
|
||||
---
|
||||
# Arcanum and McCrary Technical Team
|
||||
|
||||
<div class="team-grid">
|
||||
<div class="person">
|
||||
<img src="./eris_imgs/brown.jpg" alt="Brooks Brown headshot">
|
||||
<div class="name">Brooks Brown</div>
|
||||
<div class="role">Chief Development Architect, Co-founder (nKode inventor)</div>
|
||||
</div>
|
||||
<div class="person">
|
||||
<img src="./eris_imgs/cwhit.jpg" alt="Dr. Craig Whittinghill headshot">
|
||||
<div class="name">Dr. Craig Whittinghill</div>
|
||||
<div class="role">Deputy Director, McCrary Institute (USN Veteran)</div>
|
||||
</div>
|
||||
<div class="person">
|
||||
<img src="./eris_imgs/jsherk.png" alt="Jonathan Sherk headshot">
|
||||
<div class="name">Jonathan Sherk</div>
|
||||
<div class="role">Principal Cybersecurity Research Engineer (NSA-cert Red Team Lead)</div>
|
||||
</div>
|
||||
<div class="person">
|
||||
<img src="./eris_imgs/oeding.jpg" alt="Dr. Luke Oeding headshot">
|
||||
<div class="name">Dr. Luke Oeding</div>
|
||||
<div class="role">Associate Professor, Math & Statistics (Algebraic/Computational)</div>
|
||||
</div>
|
||||
<div class="person">
|
||||
<img src="./eris_imgs/kandah.jpg" alt="Dr. Farah Kandah headshot">
|
||||
<div class="name">Dr. Farah Kandah</div>
|
||||
<div class="role">Associate Professor, CSSE (Cybersecurity, Networks, IoT)</div>
|
||||
</div>
|
||||
<div class="person">
|
||||
<img src="./eris_imgs/DonovanKelly.png" alt="Donovan Kelly headshot">
|
||||
<div class="name">Donovan Kelly</div>
|
||||
<div class="role">CTO, Arcanum Technology (Defense, Healthcare, Auth)</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- Speakers Notes: Arcanum and McCrary Technical Team
|
||||
The nKode team represents a collaborative effort between Arcanum Technology LLC and Auburn University’s McCrary Institute for Cyber and Critical Infrastructure Security. It comprises cybersecurity experts, university professors, and innovators focused on advanced authentication solutions.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<style scoped>
|
||||
section { font-size: 18px; }
|
||||
</style>
|
||||
# Team Bios
|
||||
|
||||
- **Brooks Brown**, as the inventor and Co-founder of nKode, provides the foundational vision and architectural expertise essential for driving this innovative authentication solution forward. His role as Chief Development Architect positions him uniquely to guide the project's technical direction.
|
||||
- **Dr. Craig Whittinghill** serves as the Deputy Director for Applied Research and Services at the McCrary Institute. As a Navy Veteran with 29 years of service as a Naval Intelligence Officer, he brings extensive leadership in high-stakes cyber and intelligence operations.
|
||||
- **Jonathan Sherk** is a Principal Cybersecurity Research Engineer at Auburn University’s McCrary Institute. He leads a USDA grant on rural cybersecurity and co-leads Alabama’s State and Local Cybersecurity Grant Program. As an NSA-certified, CYBERCOM-accredited Red Team Lead, he has performed adversarial assessments on EUDs and Army products at the Threat Systems Management Office.
|
||||
- **Dr. Luke Oeding**, an Associate Professor in the Department of Mathematics and Statistics at Auburn University, contributes advanced algebraic and computational expertise critical for nKode's underlying mathematical frameworks. His research focuses on applications of algebraic geometry and representation theory to tensors, quantum information processing, signal processing, and collaborative navigation.
|
||||
- **Dr. Farah Kandah**, an IEEE Senior Member and Associate Professor in the Department of Computer Science and Software Engineering at Auburn University, as well as a faculty affiliate with the McCrary Institute, provides specialized knowledge in cybersecurity, networking, and emerging technologies like IoT and quantum credentials. His research encompasses distributed computing, computer security and reliability, computer communications (networks), and more.
|
||||
- **Donovan Kelly** brings software development experience across defense, healthcare, media, and authentication sectors, including prior work at Lockheed Martin Space. In my current role as CTO of Arcanum Technology LLC, I am actively developing new ways to apply nKode to a variety of authentication problems.
|
||||
|
||||
<!-- Speakers Notes: Team Bios
|
||||
The key members of the nKode team include Brooks Brown, who serves as the inventor, co-founder, and chief development architect; Dr. Craig Whittinghill, the deputy director and a Navy veteran with deep expertise in cyber and intelligence operations; Jonathan Sherk, a principal cybersecurity research engineer leading grants and red team assessments; Dr. Luke Oeding and Dr. Farah Kandah both associate professors at Auburn Univeristy; and Lastly me. I'm the CTO at Arcanum. I bring software development experience from defense, and healthcare sectors.
|
||||
-->
|
||||
---
|
||||
|
||||
# Defense and Commercial Market Use Case/Impact
|
||||
|
||||
- **Defense Use Cases**
|
||||
- Tactical edge authentication: Secure access to Tactical Assault Kits/comms platforms in DDIL environments
|
||||
- Warfighter resilience: Keyboard-less icons reduce errors under stress; resists keyloggers, phishing, AI attacks
|
||||
- Zero Trust enablement: Auth over unencrypted/low-bandwidth channels; integrates with C2 systems/edge compute
|
||||
- **Commercial Use Cases**
|
||||
- Banking/Healthcare: Replaces passwords for online accounts; phishing-resistant, no credential reuse
|
||||
- Dual-Use Potential: Scales to consumer apps; reduces MFA friction in high-volume sectors
|
||||
- **Market Impact ("So What")**
|
||||
- Enhances mission success/safety: Faster logins, fewer vulnerabilities in contested ops
|
||||
- Broad Adoption: Safeguards critical ops across sectors
|
||||
|
||||
<!-- Speakers Notes: Defense and Commercial Market Use Case/Impact
|
||||
nKode offers significant impact in both defense and commercial markets.
|
||||
In defense, nKode targets tactical edge challenges where current authentication systems falter.
|
||||
Commercially, nKode addresses massive markets. Replaces vulnerable passwords in banking (reducing phishing losses) or healthcare (securing patient data).
|
||||
nKode closes usability-security gaps, created by passwords.
|
||||
-->
|
||||
|
||||
---
|
||||
# Partnering with DARPA for Authentication's Next Leap
|
||||
|
||||
- **Historical Full Circle**: In 1961, DARPA (as ARPA) funded MIT's Project MAC, birthing the Compatible Time-Sharing System (CTSS), the origin of computer passwords. Now, as authentication faces escalating nation-state threats, nKode represents its disruptive evolution, closing vulnerabilities in denied, degraded, intermittent, and low-bandwidth (DDIL) scenarios.
|
||||
- **DARPA as Prime Mover**: DARPA's mission to make pivotal investments in high-risk, high-reward innovations for national security makes you the ideal partner. Your support can accelerate nKode from TRL 4 to operational deployment, enabling revolutionary advances in Zero Trust and edge computing for warfighters.
|
||||
- **Why We Need DARPA**: As our strategic catalyst, your funding, expertise, and ecosystem will scale nKode globally, ensuring resilient authentication safeguards missions and lives. This is our call to collaborate: Join us in evolving what you pioneered.
|
||||
|
||||
<!-- Speakers Notes: Partnering with DARPA for Authentication's Next Leap
|
||||
Back in 1961, ARPA, funded MIT's Project MAC, which led to the Compatible Time-Sharing System, and the very first use of computer passwords.
|
||||
DARPA is the prime mover in transformative tech. Your mission is to make pivotal investments in high-risk, high-reward innovations for national security.
|
||||
That's why we need DARPA now, as our strategic catalyst. Your funding, expertise, and vast ecosystem will help us scale nKode, ensuring resilient authentication that safeguards missions, infrastructure, bank accounts, healthcare and more. Together, we can close this 60-year loop.
|
||||
-->
|
||||
BIN
projects/arcanum/DARPA-ERIS/darpa_eris_slides.pptx
Normal file
BIN
projects/arcanum/DARPA-ERIS/eris_imgs/DonovanKelly.png
Normal file
|
After Width: | Height: | Size: 139 KiB |
BIN
projects/arcanum/DARPA-ERIS/eris_imgs/arcanum-logo.png
Normal file
|
After Width: | Height: | Size: 18 KiB |
BIN
projects/arcanum/DARPA-ERIS/eris_imgs/brown.jpg
Normal file
|
After Width: | Height: | Size: 25 KiB |
BIN
projects/arcanum/DARPA-ERIS/eris_imgs/cwhit.jpg
Normal file
|
After Width: | Height: | Size: 104 KiB |
BIN
projects/arcanum/DARPA-ERIS/eris_imgs/jsherk.png
Normal file
|
After Width: | Height: | Size: 496 KiB |
BIN
projects/arcanum/DARPA-ERIS/eris_imgs/kandah.jpg
Normal file
|
After Width: | Height: | Size: 111 KiB |
BIN
projects/arcanum/DARPA-ERIS/eris_imgs/mccrary-logo.jpg
Normal file
|
After Width: | Height: | Size: 199 KiB |
BIN
projects/arcanum/DARPA-ERIS/eris_imgs/oeding.jpg
Normal file
|
After Width: | Height: | Size: 3.1 MiB |
168
projects/arcanum/DARPA-ERIS/slides.md
Normal file
@@ -0,0 +1,168 @@
|
||||
---
|
||||
marp: true
|
||||
---
|
||||
|
||||
# nKode
|
||||
|
||||
<!--
|
||||
Hello, My name is Donovan Kelly, CTO at Arcanum Technologies. We've developed nKode, a patented pictographic passcode that reinvents authentication—making it more secure and intuitive for tactical edge environments. Arcanum has partnered with the McCrary Institute at Auburn University to leverage their cybersecurity expertise and veteran insights.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Defining the Problem
|
||||
|
||||
- Historical Context
|
||||
- Passwords as cornerstone of "something you know" authentication since 1961 (MIT's Compatible Time-Sharing System)
|
||||
- No major reinvention in over 60 years, despite evolving threats
|
||||
- Key Problems in Authentication
|
||||
- High cognitive load: 12-16 character passwords rotated every 60-90 days; prone to reuse and errors under stress
|
||||
- Vulnerabilities: Hacked at 95 per second globally; susceptible to phishing, keyloggers, and credential harvesting
|
||||
- Tactical Edge Challenges: Difficult with tactical gear (e.g., gloves); bypassed in high-risk, low-bandwidth environments; limits multi-factor authentication (MFA)
|
||||
|
||||
<!--
|
||||
Since their introduction in 1961 with MIT's Compatible Time-Sharing System, passwords have remained the cornerstone of "something you know" authentication. Yet, amid the rapid escalation of cyber threats over the ensuing six decades, this paradigm has undergone little fundamental reinvention. Passwords impose a taxing cognitive burden on warfighters, necessitating the memorization and periodic rotation of 12-16 character sequences every 60-90 days—a process prone to reuse across systems and errors amid high-stress operations. Their vulnerabilities are profound, with breaches occurring at a staggering rate of 95 per second worldwide, rendering them highly susceptible to credential harvesting. At the tactical edge, these deficiencies are amplified by environmental constraints. Inputting credentials while encumbered by tactical gear, such as gloves, proves impractical and often leads to security bypasses in high-risk, low-bandwidth scenarios that also constrain multi-factor authentication. Compounding this, AI-orchestrated attacks from nation-state actors intensify the overall threat landscape, underscoring the urgent need for evolution.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Current State of the Art
|
||||
|
||||
- Relies on static inputs: Keyboards, text-based passwords, and mental models outdated for modern threats
|
||||
- Alternatives like biometrics (facial/iris/fingerprint/voice): Effective in ideal conditions but constrained in low-light, noisy, or gloved scenarios
|
||||
- Emerging Tech: Zero Trust, edge computing, AI-driven security in systems like Tactical Assault Kits—but compromised by AI attacks, signals intelligence, and nation-state exploits
|
||||
|
||||
<!--
|
||||
The state of the art includes static text inputs and biometrics like facial recognition or fingerprints, which work well in controlled environments but falter in real-world tactical scenarios—think low light for iris scans, noise for voice, or gloves blocking fingerprints. Systems like Software-Defined Radios and Tactical Assault Kits integrate Zero Trust and edge computing for better security, but they still rely on vulnerable authentication methods that AI exploits, cognitive electronic warfare, and signals intelligence can crack. This is where nKode steps in—addressing these gaps by advancing beyond static, text-based systems to a visual, resilient alternative.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<style scoped>
|
||||
section {
|
||||
font-size: 24px; /* Adjust to a smaller value like 20px or 1.5rem; default is around 35px */
|
||||
}
|
||||
</style>
|
||||
|
||||
# How nKode Aligns with DARPA ERIS
|
||||
|
||||
- Topic area fit: Advances resilience, efficiency, and effectiveness for strategic systems across critical infrastructure and military C2 at strategic, command, operational, and tactical edges.
|
||||
- Mission tie: Supports DARPA’s aim to create technological surprise for U.S. national security.
|
||||
- nKode’s role: Reinvents “something you know” with keyboard-less, AI-generated icons to keep auth working in contested or low-bandwidth networks.
|
||||
- Surprise element: Resilient to credential reuse and keyloggers; can operate over unencrypted or bandwidth-constrained links without exposing secrets.
|
||||
- Operational benefits: Faster, low-cognitive-load access under stress; reduces bypasses and maintains mission continuity for edge tools like TAK.
|
||||
- Architectural alignment: Complements Zero Trust, edge computing, and secure operations in dynamic, degraded conditions.
|
||||
- Impact: Hardens C2 and critical infrastructure against AI-driven credential harvesting and disruption in contested environments.
|
||||
|
||||
<!--
|
||||
nKode aligns with ERIS Topic Area “advanced technologies for improved resilience, efficiency, and effectiveness of strategic systems,” including critical infrastructure and military C2 across all edges. In real-world degraded comms where passwords, OTPs, or push prompts fail or are vulnerable, nKode strengthens authentication with keyboard-less icon challenges that move over tiny or even unencrypted pipes while staying resistant to capture and replay. This yields quick, low-cognitive-load logins under stress and reduces workarounds, keeping tools like Tactical Assault Kits online. The approach supports DARPA’s goal of technological surprise by denying adversaries easy wins from phishing and keylogging and by staying operable when bandwidth and trust are scarce.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<style scoped>
|
||||
section {
|
||||
font-size: 20px; /* Adjust to a smaller value like 20px or 1.5rem; default is around 35px */
|
||||
}
|
||||
</style>
|
||||
|
||||
# Current Approaches vs. nKode
|
||||
|
||||
- How the Problem Is Addressed Today
|
||||
- Long, complex passwords (12–16 chars), rotated every 60–90 days
|
||||
- Prone to reuse, keyloggers, shoulder surfing; high cognitive load under stress
|
||||
- Requires keyboards (impractical with tactical gear); MFA often needs secure channels
|
||||
- High global breach cadence; controls get bypassed in high-risk environments
|
||||
- Biometrics (face/iris/fingerprint): fragile under duress, dirt, gloves, or low light
|
||||
- What’s New in nKode’s Approach
|
||||
- Patented virtual keypad with shuffling icons; AI-generated, user-unique icon sets
|
||||
- Vs. Passwords: No text entry; strong guessing resistance with compact inputs
|
||||
- Vs. Biometrics: No special hardware; reliable under pressure and harsh conditions
|
||||
- Backend uses a CSPRNG (e.g., ChaCha20) to drive shuffling over low-trust links
|
||||
- Resilient to keyloggers and replay; auto-rotation without user action; shoulder-surf resistant
|
||||
- Field-ready path with TRL 5 progression
|
||||
- Why It Matters at the Edge
|
||||
- Works in low-bandwidth or contested environments
|
||||
- Cuts cognitive load and speeds access, reducing bypass behavior
|
||||
- Preserves mission continuity for edge tools and C2 workflows
|
||||
|
||||
<!--
|
||||
Today, authentication relies on outdated standards, leading to credential reuse and exploitation. Passwords can be easily compromised via reuse, especially at the tactical edge where bandwidth is low and stress is high. Biometrics help but are constrained in field scenarios (e.g., gloves, environmental factors). This results in mission risks, as warfighters may bypass controls. What's new is the dynamic, visual paradigm: icons shuffle per login, mapped to tokenized values via backend cipher. Unlike static passwords or biometrics, nKode prevents reuse (unique icons) and operates in low-bandwidth environments. This compares favorably to current practices by flipping the usability-security trade-off – easier to remember yet more secure. It's TRL 5, and advances SoTA by closing attack vectors like shoulder-surfing.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Foreseen Barriers
|
||||
|
||||
- Adoption Risk: Authentication changes are high-risk; companies hesitant to be first adopters
|
||||
- Pitch History: Positive feedback from dozens (e.g., FIS, banks) over 10 years, but no implementations
|
||||
- Technical: Integration with legacy DoD systems; user training; device compatibility (rugged tablets)
|
||||
- Evolving Threats: Advanced AI shoulder-surfing; scaling to millions/billions of unique, psychologically neutral icons to prevent AI prediction of user selections
|
||||
- Mitigation: Leverage ERIS for rapid pathways; partner with McCrary Institute for validation
|
||||
|
||||
<!--
|
||||
Barriers include institutional inertia—despite excitement from fintech like FIS (Fidelity National Information Services), no one wants to pioneer due to perceived risks. In DoD, integrating with C2 systems or ATACs could face hurdles. Scaling icon generation is key: we need millions or billions of AI-generated icons that are unique and psychologically neutral (free of biases that could make selections predictable), ensuring no AI can train on patterns for attacks. We'll address this via human factors expertise (as per prior feedback), field testing, and ongoing R&D—nKode's design inherently resists many exploits, but this requires advanced AI safeguards.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Why nKode Will Succeed
|
||||
|
||||
- Market Validation: Independent survey by User Insight – 52% prefer nKode (vs. 28% passwords)
|
||||
- High Acceptance: 17% above "very high" benchmark (35%)
|
||||
- Team Strength: Veterans with cyber ops experience; TRL 5 proven
|
||||
- Dual-Use Potential: Defense (tactical edge) + Commercial
|
||||
- Evidence: Exceeds benchmarks; low friction deployment
|
||||
|
||||
<!--
|
||||
Success is backed by data: User Insight's survey showed exceptional preference (52%), far above norms, indicating strong usability. Our team's expertise (Army/Navy vets) and partnerships ensure execution. nKode's success lies in its intuitive design – users remember one nKode for all, with auto-rotation. This will drive adoption, per ERIS goals, leading to safer operations.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Proposed Plan/Strategy if Funded
|
||||
|
||||
- Phase 1: Adapt commercial app for tactical edge; integrate with ATACs/Tactical Assault Kits
|
||||
- Phase 2: Field validation/testing in simulated environments; address barriers (training/integration)
|
||||
- Phase 3: Advance to TRL 6-7; deploy OpenID Connect for DoD systems
|
||||
- Timeline: 12-18 months; focus on low-bandwidth resilience
|
||||
- Outcomes: Prototype for warfighters; pathway to commercialization
|
||||
|
||||
<!--
|
||||
If funded, we'll pivot our existing commercial app (with OpenID/OAuth support) to defense needs. Develop a glove-friendly version for tactical edges, sans biometrics. Strategy: Collaborate with McCrary for demos and integration. Budget for AI enhancements and testing. This aligns with ERIS's rapid acquisition, transitioning from idea to prototype for enhanced strategic system resilience.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Arcanum and McCrary Technical Team
|
||||
|
||||
pictures
|
||||
|
||||
<!--
|
||||
The nKode team is a unified collaboration between Arcanum Technology LLC and Auburn University’s McCrary Institute for Cyber and Critical Infrastructure Security. Brooks Brown, as the inventor and Co-founder of nKode, provides the foundational vision and architectural expertise essential for driving this innovative authentication solution forward. His role as Chief Development Architect positions him uniquely to guide the project's technical direction. Dr. Craig Whittinghill serves as the Deputy Director for Applied Research and Services at the McCrary Institute. As a Navy Veteran with 29 years of service as a Naval Intelligence Officer, he brings extensive leadership in high-stakes cyber and intelligence operations. Jonathan Sherk is a Principal Cybersecurity Research Engineer at Auburn University’s McCrary Institute. He leads a USDA grant on rural cybersecurity and co-leads Alabama’s State and Local Cybersecurity Grant Program. As an NSA-certified, CYBERCOM-accredited Red Team Lead, he has performed adversarial assessments on EUDs and Army products at the Threat Systems Management Office. Dr. Luke Oeding, an Associate Professor in the Department of Mathematics and Statistics at Auburn University, contributes advanced algebraic and computational expertise critical for nKode's underlying mathematical frameworks. His research focuses on applications of algebraic geometry and representation theory to tensors, quantum information processing, signal processing, and collaborative navigation. Dr. Farah Kandah, an IEEE Senior Member and Associate Professor in the Department of Computer Science and Software Engineering at Auburn University, as well as a faculty affiliate with the McCrary Institute, provides specialized knowledge in cybersecurity, networking, and emerging technologies like IoT and quantum credentials. His research encompasses distributed computing, computer security and reliability, computer communications (networks), and more. Lastly me. I have over seven years of software development experience across defense, healthcare, media, and authentication sectors, including prior work as a Space Ground Software Engineer at Lockheed Martin. In my current role as CTO of Arcanum Technology LLC, I am actively developing new ways to apply nKode to a variety of authentication problems.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<style scoped>
|
||||
section {
|
||||
font-size: 24px; /* Adjust to a smaller value like 20px or 1.5rem; default is around 35px */
|
||||
}
|
||||
</style>
|
||||
|
||||
# Defense and Commercial Market Use Case/Impact
|
||||
|
||||
- Defense Use Cases
|
||||
- Tactical edge authentication: Secure access to Tactical Assault Kits/comms platforms in DDIL environments
|
||||
- Warfighter resilience: Keyboard-less icons reduce errors under stress; resists keyloggers, phishing, AI attacks
|
||||
- Zero Trust enablement: Auth over unencrypted/low-bandwidth channels; integrates with C2 systems/edge compute
|
||||
- Commercial Use Cases
|
||||
- Banking/Healthcare/Infrastructure: Replaces passwords for online accounts; phishing-resistant, no credential reuse
|
||||
- Dual-Use Potential: Scales to consumer apps; reduces MFA friction in high-volume sectors
|
||||
- Market Impact ("So What")
|
||||
- Enhances mission success/safety: Faster logins, fewer vulnerabilities in contested ops
|
||||
- Broad Adoption: Safeguards critical ops across sectors
|
||||
|
||||
<!--
|
||||
nKode offers significant impact in both defense and commercial markets, emphasizing the "so what" through practical applications and outcomes. In defense, nKode targets tactical edge challenges where current systems (e.g., passwords/biometrics) falter in DDIL scenarios (Denied, Disrupted, Intermittent, and Limited bandwidth/comms): Warfighters authenticate to secure comms or field kits via intuitive icons, resilient without full encryption, reducing bypass risks and improving continuity amid nation-state threats like signals intelligence. The impact? Stronger defenses, mission success, and warfighter safety. Commercially, it addresses massive markets: Replaces vulnerable passwords in banking (reducing phishing losses) or healthcare (securing patient data), with dual-use for infrastructure like utilities. The "so what": nKode closes usability-security gaps, potentially mitigating the $10.5T in annual global cybercrime costs by 2025, while enabling Zero Trust across sectors. If funded, we'll validate these via DoD pilots and commercial integrations for rapid transition.
|
||||
-->
|
||||
3
projects/arcanum/NSF/1.16.26 NSF meeting.md
Normal file
@@ -0,0 +1,3 @@
|
||||
- Maybe a simple table that shows our claim of 5 observation
|
||||
- Need to show why we are different: we don't specify an exact code we are probablistic
|
||||
- Thyaga thinks this is weak: Defensible competitive advantage. we need to explain why we are different from other systems
|
||||
42
projects/arcanum/NSF/Clarifying nKode v2.md
Normal file
@@ -0,0 +1,42 @@
|
||||
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 shuffled layout 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 and graphical password systems have been studied extensively. nKode’s novelty is not “using pictures,” and not merely “shuffling a keypad.” The core difference is the combination of (a) a stable, memorable secret defined over attributes, (b) randomized grouping of a larger displayed attribute set into a small fixed input alphabet (key IDs), and (c) parametrizable resistance to capture and inference via repeated sessions, while remaining compatible with high-throughput PoS and ATM constraints (small screens, fast entry, minimal user training, no extra sensors).
|
||||
|
||||
Security motivation and threat model fit for PoS:
|
||||
Today’s PoS skimmers typically steal card data and capture a static ZIP code or PIN. With nKode, a simple tap-and-log skimmer that records key presses is insufficient because the key press sequence is only meaningful when paired with the corresponding on-screen challenge. An attacker would need to add a camera (or equivalent screen capture) and then solve an inference problem across multiple observations of the same user to recover the underlying attributes. Based on our work with McCrary, we target configurations where an attacker needs on the order of 5 or more sequential observations to reliably recover a user’s nKode.
|
||||
*comparied to static data....*
|
||||
|
||||
High-risk, high-reward R&D:
|
||||
The technical risk is achieving a strong security–usability frontier concurrently: fast entry time, low error rate, accessibility variants, and quantified resistance to recording and inference attacks. Our Phase I work will produce (1) formal parameterization of layouts, group sizes, and session policies, (2) empirical usability results on realistic PoS/ATM workflows, and (3) measured attack resistance against key-logging, shoulder surfing, and screen-recording plus inference baselines.
|
||||
|
||||
Defensible competitive advantage:
|
||||
Our patent claims cover a broad design space of attribute types (images/emojis, alphanumeric symbols, audio cues for visually impaired users, tactile patterns such as braille-like textures) and the grouping/shuffling mechanism across spatial, auditory, tactile, or label-based key groupings. This makes “simple re-skins” and modality pivots harder for fast followers.
|
||||
64
projects/arcanum/NSF/Clarifying nKode v3.md
Normal file
@@ -0,0 +1,64 @@
|
||||
_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) Fast, low-friction entry compatible with checkout throughput. Unlike many shoulder-surfing-resistant schemes that require multiple challenge rounds or complex mental transformations, nKode preserves a “type-a-short-code” interaction: users enter a short sequence of key IDs derived from a single on-screen layout. While we will quantify entry time and error rate in Phase I, prior work on shuffled keypads suggests that small increases in entry time relative to a static keypad can be achieved without fundamentally changing the interaction model.
|
||||
|
||||
(b) Designed to remain resistant under multiple recorded observations (not just one). A common limitation of observation-resistant schemes is that they degrade quickly when an attacker can record several sessions. 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 with high confidence.
|
||||
|
||||
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).
|
||||
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).
|
||||
46
projects/arcanum/NSF/Clarifying nKode.md
Normal file
@@ -0,0 +1,46 @@
|
||||
_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._
|
||||
|
||||
|
||||
Below is an example of a virtual keypad with 4 keys and 4 emojis per key. Suppose my icons are 😍🤢🤐🥸. At the keypad terminal, I'd enter: 1,4,4,2
|
||||
```
|
||||
_key1_ _key2_
|
||||
| 😃😍 | | 🥸🤩 |
|
||||
| 😇😎 | | 🤓🥳 |
|
||||
----- -----
|
||||
_key3_ _key4_
|
||||
| 🥺🤯 | | 🫥🤥 |
|
||||
| 😡🥶 | | 🤢🤐 |
|
||||
----- -----
|
||||
```
|
||||
After I successfully authenticate, my keypad gets shuffled. When I make another purchase, I'd enter 1,2,1,1
|
||||
```
|
||||
_key1_ _key2_
|
||||
| 🫥😍 | | 🥸🤥 |
|
||||
| 😇🤐 | | 🤢🥳 |
|
||||
----- -----
|
||||
_key3_ _key4_
|
||||
| 😃🤯 | | 🥺🤩 |
|
||||
| 😡😎 | | 🤓🥶 |
|
||||
----- -----
|
||||
```
|
||||
|
||||
This design thwarts credit card (cc) skimmers because they steal the cc number and log the zip code or debit card PIN. With nKode, skimmers would have to incorporate a camera to monitor the screen as well. What's more, they'd have to watch a user enter their nKode 5 times (based on our work with McCrary) to determine the nKode. Most skimmers are left on a cc terminal for at most a day. Thieves try to collect a few hours' worth of transactions, retrieve their skimmer, and move on to the next store to avoid getting caught and losing their skimmer (and the stolen data). The combination of requiring a camera and requiring multiple observations of the same cc/debit card on the same terminal over the course of a day is impractical. It's rare for one person to use a cc on the same terminal 5 times over the course of a week, let alone a day.
|
||||
|
||||
There aren't any authentication systems that work like nKode. It is the first change to something-you-know authentication since MIT first invented username/password. At Arcanum, we advertise nKode, a pictographic passcode in the shape of a keypad, but our patent covers a broad range of designs and attributes. The keypad design is well-suited for PoS/ATMs, with a virtual keypad on the screen that mirrors the physical keypad on the terminal; however, nKode is not limited to icons or keypad shapes. For the visually impaired, our patent covers audio attributes grouped into keys. For numeric data such as SSNs, keypad attributes can be entirely numeric. In desktop/mobile applications, icons can remain static while key numbers move to them. For example, the nKode displayed below can be entered on a keyboard. With icons 😍🤢🤐🥸, a user would type 1,2,1,1, the same as the second keypad above.
|
||||
|
||||
```
|
||||
😃:3, 🥸:2, 🥺:4, 🫥:1
|
||||
😍:1, 🤩:4, 🤯:3, 🤥:2
|
||||
😇:1, 🤓:4, 😡:3, 🤢:2
|
||||
😎:3, 🥳:2, 🥶:4, 🤐:1
|
||||
|
||||
```
|
||||
With the keypad arranged like it is above, the keys don't need to be numeric either.
|
||||
```
|
||||
😃:c, 🥸:b, 🥺:d, 🫥:a
|
||||
😍:a, 🤩:d, 🤯:c, 🤥:b
|
||||
😇:a, 🤓:d, 😡:c, 🤢:b
|
||||
😎:c, 🥳:b, 🥶:d, 🤐:a
|
||||
```
|
||||
|
||||
In summary, nKode's moat is that we have a patent that covers a broad range of attributes: images, emojis, alphanumeric symbols, sounds, textures (like braille), and shuffles them in spatial(keys), auditory, tactile, or alphanumeric groups. CISOs and users want nKode. Users like nKode because it's easy to remember. CISOs want it because it eliminates key-logging, shoulder surfing, and password reuse.
|
||||
21
projects/arcanum/NSF/NSF Section 1.md
Normal file
@@ -0,0 +1,21 @@
|
||||
## Prompt
|
||||
Explain the core high-risk technical innovation to be researched and developed during a Phase I project.
|
||||
NSF must understand what research and development is required and how this technical innovation differs from and is significantly better than existing solutions.
|
||||
It may also be that the proposed innovation creates a new market.
|
||||
In this case, why will it be adopted?
|
||||
Describing features or benefits of the proposed technology is not sufficient.
|
||||
|
||||
The FBI estimates that more than a billion dollars are lost every year to credit card skimmers. Thevies steal card information and PIN numbers to steal from unsuspecting customers. Skimmers are esencially keyloggers. They steal the debit/credit card number along with they customers PIN or zip code. nKode is designed to stop the lose of information on the keypad. The users nKode is a pictographic passcode that can be entered either directly on the screen or with the keypad. Since scimmers can't see or record the screen, the pincode entered by the user is useless. Even if the skimmer could record the screen and process the infomation, an nKode can handle 4 observation before the skimmer could learn the nKode on the 5th observation. nKode can be intergrated into existing ATM/PoS(Point-of-sales) systems. nKode uses the same standards for hashing and encrypting as password/passcodes too. There is a $1billion dollar per year insentive to use nKode a a replacement for pins. A 4 icon nKode has orders of magnatude more entropy than a pincode of equvalent length......
|
||||
|
||||
|
||||
|
||||
nKode represents a fundamental reinvention of authentication through a dynamic, pictographic passcode system that eliminates dependence on traditional alphanumeric passwords or static biometric inputs.
|
||||
At its core, nKode is a patented, keyboard-less authentication interface using a randomized, icon-based keypad. This innovation addresses a long-standing vulnerability in digital security—the reliance on memorized text strings that are prone to reuse, theft, and human error.
|
||||
|
||||
Unlike conventional systems, nKode leverages an AI-generated icon set assigned to each user, where icons are grouped and reshuffled across a virtual keypad on each login. The technical novelty lies in the backend use of transient, system-assigned values that are detached from what the user visually selects. This separation allows the system to change internal mappings without disrupting the user experience.
|
||||
|
||||
nKode's security is further bolstered by high entropy in user-selected passcodes, drawing from password entropy research that emphasizes the importance of randomness and resistance to guessing attacks. Research is still need to determine the minimum passcode length. With a minimum set of 54 unique AI-generated icons and order-dependent selection, a 4-icon nKode has over 23-bits of entropy (exceeding the NIST recommendation of at least 20-bits for randomly generated memorized secrets). nKode complies with NIST guidelines by enforcing non-dictionary-searchable patterns, eliminating keyboard-based input (eliminating keylogger risk), and supporting periodic backend renewal without user intervention. When nKode is entered with a keyboard, the numbers entered appear random to keyloggers.
|
||||
|
||||
The platform uses multiple layers of security: dynamic reshuffling, ciphering of user inputs, renewable backend attributes, and passcode hashing. Together, these form an authentication process resilient to phishing, replay attacks, and keyloggers that is capable of functioning securely over unencrypted or degraded channels.
|
||||
|
||||
nKode’s architectural model enables a new market of secure, portable, and infrastructure-light authentication—extending MFA into environments (tactical, industrial, mobile) where traditional methods fail. It also offers a scalable and user-centric alternative for commercial applications like fintech, healthcare, and identity-first zero trust systems.
|
||||
9
projects/arcanum/NSF/NSF feedback.md
Normal file
@@ -0,0 +1,9 @@
|
||||
- nkode should be opt-in
|
||||
- old atms shouldn't use nkode (use your old pin on legacy hardware)
|
||||
- we won't hit every user. just like magnetic card strips are still used...
|
||||
- we've done preliminary test for such and such a case... We are interested in studying other things...
|
||||
# Arcanum
|
||||
- usability study 68% approval rating in usability study. after creating their first nKode it was 63% approval rating. 35% approval for new technology is a very high score.
|
||||
- FIS MVP out of their venture center accelerator
|
||||
- Need to better describe nKode
|
||||
-
|
||||
31
projects/arcanum/Tabletop Discussion.md
Normal file
@@ -0,0 +1,31 @@
|
||||
|
||||
## 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
|
||||
|
||||
|
||||
|
||||
|
||||
73
projects/arcanum/sofwerx-slides.md
Normal file
@@ -0,0 +1,73 @@
|
||||
# Sofwerx Slides
|
||||
|
||||
## Slide 1
|
||||
|
||||
### Speakers Notes
|
||||
|
||||
Imagine a world where warfighters and civilians can authenticate securely without passwords, even in the most challenging environments. That’s the vision behind nKode.
|
||||
Our mission is to deploy a secure, intuitive, and scalable authentication technology for the tactical edge. nKode’s keyboard-less, icon-based interface modernizes the ‘something only you know’ factor of multi-factor authentication, eliminating vulnerabilities tied to traditional passwords.
|
||||
We’re not doing this alone. Arcanum has partnered with Auburn University’s McCrary Institute, a hub for national security expertise, providing strategic validation.
|
||||
Together, we’re building a solution that redefines authentication for defense and beyond, ensuring security and usability in critical operations.
|
||||
Let’s dive into how nKode makes this a reality.
|
||||
|
||||
## Slide 2 Modern Warfighter Communication and Authentication
|
||||
|
||||
### Speakers Notes
|
||||
|
||||
Let’s start with how modern warfighters communicate and authenticate at the tactical edge. The focus is on secure, mobile systems that keep our forces connected and protected.
|
||||
Software-Defined Radios, or SDRs, allow flexible, encrypted communications that adapt to mission needs. Tactical Assault Kits provide real-time data sharing for better decision-making. Zero Trust frameworks ensure no device or user is automatically trusted, requiring continuous verification.
|
||||
Edge computing processes data closer to the battlefield, reducing latency. AI-driven security analyzes threats in real time, adapting to new risks dynamically.
|
||||
Together, these systems give warfighters information superiority, ensuring they can act faster and smarter, even in chaotic, contested environments.
|
||||
But these advancements come with challenges.
|
||||
## Slide 3 Current and Future Challenges
|
||||
|
||||
### Speakers Notes
|
||||
|
||||
Now, let’s look at the hurdles facing these systems, both today and moving forward.
|
||||
Many warfighters, especially disadvantaged users, rely on line-of-sight, low-bandwidth communications. This restricts data throughput, making it tough to implement robust multifactor authentication, which needs more bandwidth to function effectively.
|
||||
Warfighters often struggle with complex password requirements for device authentication. This difficulty leads to devices being left unlocked or open to bypass authentication, increasing the risk of mission compromise if a device is captured by adversaries.
|
||||
AI-driven attacks are a growing concern, exploiting weaknesses faster than traditional defenses can respond. Nation-states wield advanced tools like cognitive electronic warfare to jam signals, signals intelligence to intercept communications, and cyber exploits to breach authentication systems.
|
||||
These vulnerabilities can compromise operational security, putting missions and lives at risk.
|
||||
Addressing these challenges requires innovative solutions to ensure our warfighters stay secure and connected in the future.
|
||||
|
||||
## Slide 4 nKode Authentication Solution
|
||||
|
||||
### Speakers Notes
|
||||
|
||||
Let’s dive into nKode, a revolutionary authentication solution designed for warfighters at the tactical edge.
|
||||
nKode uses a keyboard-less system with AI-generated icon codes. These are unique, easy to remember, and meet NIST security standards, ensuring robust protection.
|
||||
It tackles common weaknesses like keyloggers, credential reuse, and risks from unencrypted channels, outperforming traditional passwords and biometrics.
|
||||
Best of all, nKode works seamlessly over low-bandwidth, unencrypted channels, perfect for austere tactical environments.
|
||||
|
||||
## Slide 5 Benefits and Impact
|
||||
### Speakers Notes
|
||||
Now, let’s look at how nKode delivers value to warfighters and mission success.
|
||||
nKode’s design resists AI-driven attacks and sophisticated nation-state cyber threats, ensuring operational security even in contested environments.
|
||||
Its intuitive design make authentication simple, reducing user error and speeding up access under pressure. Large keys make authentication easy even with gloves. An nKode is as secure as a password that’s twice its length, so an 8-icon nkode is as secure as an 16 character password.
|
||||
By enabling secure, reliable communication, nKode sets a new standard for tactical authentication, giving warfighters a critical edge.
|
||||
|
||||
## Slide 6 nKode Enrollment
|
||||
### Speakers Notes
|
||||
Let’s take a look at nKode enrollment. The enrollment process is designed to mimic the login process.
|
||||
The enrollment process has two simple steps. First, the user selects their desired nKode by choosing keys with icons they like, in this case the warfighter selects "dog-tags", "drone", "ghillie suit", and "humvee".
|
||||
In the second step, the warfighter confirms their nKode by select keys with the same icons in the same order.
|
||||
Now our warfighter has a secure, unique and memorable nKode.
|
||||
This user-friendly design helps warfighters quickly select their nKode, even in high-pressure situations.
|
||||
This streamlined process makes nKode both easy to use and highly secure.
|
||||
## Slide 7 Login
|
||||
### Speakers Notes
|
||||
Now, let’s explore how nKode’s randomly shuffling keypad delivers unmatched security for warfighter authentication.
|
||||
nKode eliminates numerous attack vectors, like keyloggers and credential theft, that plague traditional systems. Its innovative design ensures that even sophisticated attacks struggle to compromise it.
|
||||
Here’s why: with each authentication, the keypad’s icons randomly shuffle after every login. This means the layout changes every time, so even if someone watches you enter your nKode repeatedly, they can’t figure it out.
|
||||
Also, you might notice the keypad is a bit different from the enrollment keypad.
|
||||
After enrollment, icons are added to each key to make it phishing resistant. This makes it difficult for scammers to take a user through a similar process to enrollment.
|
||||
This dynamic shuffling makes it virtually impossible to guess or steal a user’s nKode, providing a level of security that’s critical in contested environments where adversaries might observe or intercept.
|
||||
With this approach, nKode ensures warfighters can authenticate confidently, no matter the threat.
|
||||
|
||||
## Slide 8 The "So What" of nKode
|
||||
### Speakers Notes
|
||||
So, why does nKode matter? Let’s look at its broader impact.
|
||||
nKode combines robust encryption and authentication into a single, intuitive system. It’s secure yet easy to use, addressing a key pain point in both defense and commercial settings.
|
||||
For warfighters, it protects critical operations in contested environments. For civilians, it secures transactions and accounts, countering cyber threats like never before.
|
||||
Ultimately, nKode sets a global standard for authentication—simple, secure, and ready for the challenges of today and tomorrow.
|
||||
With nKode, we’re paving the way for safer systems across the board.
|
||||
18
projects/nkode/AU Ask for Craig.md
Normal file
@@ -0,0 +1,18 @@
|
||||
# Meeting Notes 12/2/24: AU Ask for Craig
|
||||
|
||||
### Highest Priority
|
||||
- Cipher: Validate our passcode and set cipher.
|
||||
|
||||
- Shuffle: Quantify our shuffle algorithm with different policies. Given a policy, what's the average number of observations to crack an nKode? What's the variance? What does the distribution curve look like?
|
||||
|
||||
### Middle Priority
|
||||
- Database: Analysis of database encryption. What are the security implications of encrypting different parts of our database? What's the minimum amount of encryption we can do?
|
||||
|
||||
### Low Priority
|
||||
- DARC: Analyis our post quantum passkey (aka DARC)
|
||||
|
||||
|
||||
|
||||
Start off with by quantifing, and qualifing our shuffle algorithm and passcode cipher. We'll need some statistics people on the shuffle algo and encryption people on the cipher.
|
||||
|
||||
After that, we'll need encryption people to help use figure out what the minimum about of encryption we can do with our database.
|
||||
48
projects/nkode/Eagle Venture Lab application.md
Normal file
@@ -0,0 +1,48 @@
|
||||
# Eagle Venture Lab
|
||||
|
||||
## Step 1
|
||||
|
||||
### Your Elevator Pitch should summarize the problem that needs to be addressed and why your startup is the best solution to that problem.
|
||||
|
||||
#### 30-Second Elevator Pitch (100 words max)*
|
||||
Password authentication has two main problems.
|
||||
1) People choose bad passwords. Only 1/3 of Americans use password managers. The other 2/3rds pick their own, and most people choose bad passwords.
|
||||
2) People reuse their bad passwords on multiple sites. If you aren't using a password manager, you're likely reusing the same password over and over.
|
||||
|
||||
nKode is a pictographic passcode where users can only choose a strong passcode, and no two people will be able to choose the same passcode.
|
||||
|
||||
### One-Sentence Pitch (25 words max)*
|
||||
|
||||
nKode is a pictographic passcode that is easier to remember and more secure than a password.
|
||||
|
||||
### Briefly describe your revenue model for your offering (50 words max)*
|
||||
|
||||
We have two revenue models.
|
||||
1) B2B model: nKode is used by businesses for employee authentication.
|
||||
|
||||
2) B2C model: nKode is used by individuals to login into their accounts as you would with "Sign in with Google" or "Sign in with Apple". Arcanum Technology creates services like Clerk.com or Auth0.com.
|
||||
|
||||
|
||||
### Briefly describe your startup's journey to date:
|
||||
|
||||
- Tell us about yourself and why you started the business
|
||||
- Describe your team and how they came together, if applicable
|
||||
- How have you validated your idea?
|
||||
- How have you executed on your idea?
|
||||
- What is your greatest need to help you get launched?
|
||||
|
||||
Brooks Brown invented nKode after a credit card skimmer stole his debit card pin number. nKode prototype version was a modified keypad with numbers instead of images.
|
||||
Before the pandemic, Arcanum developed nKode for banks and financial institutions. Most financial institutions we've approached over the years want to use nKode, but none want to be the first to integrate it.
|
||||
I'm the most recent founder to join Arcanum. I joined because I saw a company with a patent for an incredible technology that could dominate the identity and access management space.
|
||||
Since joining, I've also developed nKode Gen2 an even more secure implementation of nKode.
|
||||
We've also pivoted from trying to sell nKode to finding a strategic partner. We need a large company or institution with industry trust to stand behind our technology.
|
||||
|
||||
### Briefly describe your go-to-market plan, including how you will acquire customers and any applicable sales channels you plan on selling through (50 words or less)
|
||||
|
||||
Our Go-to-Market plan is to find strategic partners in industry or academia with cybersecurity expertise to validate our technology. With the backing of our strategic partner, we'll reapproach the companies that expressed interest in nKode but were unwilling to try it first.
|
||||
|
||||
### Briefly describe your potential exits and the profile of the mostly likely acquirer of your company (50 words or less)*
|
||||
|
||||
Our exit strategy is to be acquired by a company in the identity and access management space. A company like Okta has the most to gain with a Arcanum's patent.
|
||||
|
||||
|
||||
113
projects/nkode/OpenID Connect Passport Notes.md
Normal file
@@ -0,0 +1,113 @@
|
||||
## Ch. 2
|
||||
|
||||
## Ch. 3 OpenId Connect Endpoints
|
||||
##### 3.1 Authorization Endpoint
|
||||
- displays authentication and consent screen
|
||||
- returns `authorization_code` See ch. 5
|
||||
- client initiates the call to the authorization endpoint
|
||||
###### 3.1.2 input parameters with examples
|
||||
```
|
||||
scope: openid profile email address phone
|
||||
response_type: code (backend flow) || id_token token (frontend flow) || code id_token (hybrid)
|
||||
client_id: id of the client
|
||||
redirect_uri: redirect url
|
||||
state: cross-site scripting protection
|
||||
nonce: required for implict flow (frontend flow)
|
||||
Optional Params: (more research on each)
|
||||
claims:
|
||||
display:
|
||||
prompt:
|
||||
max_age: maximum lifetime of the token in seconds after which the user must re-authenticate
|
||||
ui_locales:
|
||||
id_token_hint:
|
||||
login_hint:
|
||||
acr_values:
|
||||
```
|
||||
|
||||
###### 3.1.3 Output
|
||||
Sends authentication and access delegation (authorization) tokens to redirect endpoint. Token/s are sent as an HTTP 302 redirect.
|
||||
|
||||
##### Ch 3.2 Resource Endpoint
|
||||
Managed by the resource provider. Serves protected resources to authorized parties. valid OAuth `access_token` required
|
||||
|
||||
##### Ch 3.3 Userinfo Endpoint
|
||||
This is a resource endpoint `/userinfo` that serves profile information of the authenticated end-user.
|
||||
This endpoint returns a list of claims like DOB, name, email, phone_number, profile_picture or any other claim.
|
||||
This is Defined in the OpenID Connect Standard.
|
||||
To the OAuth server, it's just a resource endpoint.
|
||||
1) Will typically be a GET request but should support POST (not sure why)
|
||||
2) should support CORS
|
||||
3) Should return JSON `Content-Type: application/json` Might need to be a JWT `Content-Type: application/jwt`
|
||||
```
|
||||
List of Claims:
|
||||
sub: something to id the user
|
||||
name
|
||||
family_name
|
||||
preferred_username
|
||||
picture
|
||||
email
|
||||
birthday
|
||||
zoneinfo: time zone
|
||||
updated_at: last updated to the profile
|
||||
Other Claims:
|
||||
nonce
|
||||
auth_time
|
||||
at_hash: access_token hash
|
||||
c_hash: authorization_code hash
|
||||
acr: more research
|
||||
amr: more research
|
||||
sub_jwk: public key to check the signature of the id_token
|
||||
```
|
||||
|
||||
##### 3.4 Token Endpoint
|
||||
Called by the Client.
|
||||
Client sends client_id, client_secret, and authorization_code to get an access_token, refresh_token, or id_token
|
||||
|
||||
```
|
||||
Client->/token
|
||||
HTTP header
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
Authorization: Basic {Base64URL-encoding(clientID:clientSecret)}
|
||||
|
||||
Form Parameters:
|
||||
grant_type: authorization_code
|
||||
code: the authorization_code proved by the authorization endpoint
|
||||
redirect_ur: redirect URL
|
||||
|
||||
Response:
|
||||
Header:
|
||||
Cache-Control: no-store
|
||||
Pragma: no-cache
|
||||
Body:
|
||||
{
|
||||
expires_in: access_token expiration in seconds,
|
||||
access_token: OAuth access_token,
|
||||
token_type: access token type `Bearer`,
|
||||
refresh_token: OAuth refresh_token,
|
||||
id_token: id_token for the end user
|
||||
}
|
||||
```
|
||||
###### 3.4.4 Validations at the Token Endpoint
|
||||
- Authenticate the client
|
||||
- validate authorization_code
|
||||
- was issued to client
|
||||
- is valid
|
||||
- hasn't been used
|
||||
- validate redirect_uri matches pre-registered value
|
||||
##### 3.5 Redirect Endpoint
|
||||
authorization endpoint delivers `id_token, access_token, authorization_token`
|
||||
|
||||
## Ch. 4 Tokens in OpenID Connect
|
||||
|
||||
```
|
||||
id_token
|
||||
access_token
|
||||
refresh_token
|
||||
authorization_code
|
||||
```
|
||||
|
||||
##### Two types of tokens:
|
||||
###### Reference Tokens
|
||||
- Randomly Generated String
|
||||
- Opaque
|
||||
-
|
||||
16
projects/nkode/email to Founder University.md
Normal file
@@ -0,0 +1,16 @@
|
||||
# Email to Founder University
|
||||
|
||||
Hi Kelly and Lukas,
|
||||
|
||||
Thank you for taking the time to review our application. We're so delighted to have received an acceptance from you. It means a lot to me and the team that you'd include us in your 9th cohort.
|
||||
|
||||
I'm a big fan of the All In Podcast and This Week in Startups, so I leaped at the opportunity without considering whether I'd be a good fit for Founder University. After a deeper look at the program, I don't think we'd be a good fit.
|
||||
|
||||
My cofounders and I have been trying to get our technology into mostly fintech companies for over five years, and there is a lot of interest in nKode. Despite this interest, companies are unwilling to do so with a technology that has yet to be widely adopted or has the backing of a trusted identity provider.
|
||||
|
||||
This year, we have shifted our focus to finding a strategic partner (like Okta or Microsoft) with the credibility to back nKode as a secure authentication technology.
|
||||
|
||||
Here's our ask: can we set up a meeting with you or someone on your team to help us find a strategic partner?
|
||||
|
||||
Thanks,
|
||||
Donovan
|
||||
@@ -0,0 +1,8 @@
|
||||
# Why do you want to apply to this program? What are your expectations?
|
||||
My cofounders and I have been trying to get our technology into mostly fintech companies for over five years, and there is a lot of interest in nKode. Despite this interest, companies are unwilling to do so with a technology that has yet to be widely adopted or has the backing of a trusted identity provider. We hope this will lead us to a strategic partner with the credibility to take nKode to market.
|
||||
|
||||
# How can you contribute to the success of other startups in your cohort?
|
||||
As CTO of Arcanum Technology, I can contribute to the success of other startups by sharing my technical expertise in LLM/RAG development and authentication. I have experience accross a wide domain of tech stacks from embedded system to web development. I can provide mentorship on technicial problems other in my cohort migh have.
|
||||
|
||||
# Tell us about the founding team story
|
||||
Brooks Brown, the inventor of nKode, got the idea for it when a family friend had their debit card number and pin stolen from credit card skimmer. He originally developed nKode as a way to make skimming impossible.
|
||||
18
projects/nkode/nkode_tasks_before_marketing.md
Normal file
@@ -0,0 +1,18 @@
|
||||
# nKode Tasks Before Marketing
|
||||
|
||||
|
||||
## TODO in todoist
|
||||
|
||||
- sqlite cron job backup
|
||||
- fail2ban
|
||||
- logging and detailed errors
|
||||
- Improve UX: remove example keypad, example what do to in set and confirm, fix bg color
|
||||
|
||||
## TODO not in todoist
|
||||
- Written Documentation at docs.nkode.tech
|
||||
- Video Documentation on Youtube
|
||||
- What should the user see when they log in?
|
||||
|
||||
## DONE
|
||||
|
||||
- Email Verification and Forgot Password
|
||||
184
projects/nkode/nkode_tutorial.md
Normal file
@@ -0,0 +1,184 @@
|
||||
# nKode Tutorial
|
||||
|
||||
## nKode Keypad
|
||||
|
||||
- nKode keypad contains keys
|
||||
- Each key has icons
|
||||
- Each icon belongs to a set and has an index value associated with it
|
||||
- The position within the key is the set value
|
||||
- When attributes are shuffled, they'll always remain in the same position within the key
|
||||
(note: the set value can be obuscated from the client but we find it helpful to quickly find the attribute)
|
||||
|
||||
## nKode Enrollment
|
||||
|
||||
- user sets then confirms their nKode
|
||||
- Set and Confirm are dipersion of each other and allow the server to infer the users nKode
|
||||
- the users login has additional icons added to each to key to make it dispersion resistant
|
||||
- After the user as selected their nKode through the set and confirms,
|
||||
the server can infer the users selection since each key selection will only have one icons in common.
|
||||
- The users nKode is enciphered, salted and hashed.
|
||||
|
||||
## Dispersion
|
||||
|
||||
- Two keypads are dispersion of each other if:
|
||||
Kp1: Keypad 1
|
||||
Kp2: Keypad 2
|
||||
|
||||
for each key1 in Kp1:
|
||||
for each key2 in Kp2:
|
||||
iconsIntersection(key1, key2) <= 1
|
||||
|
||||
|
||||
## Dispersion Algo
|
||||
|
||||
- Convert a Keypad view into a matrix view
|
||||
- each row is key and each column is a set
|
||||
- Fisher Yates the keys i.e. the rows in the matrix
|
||||
- Fisher Yates an identity matrix equivalent to the number of keys
|
||||
- The shuffled permutation is used to rotate the columns
|
||||
|
||||
|
||||
## Dispersion Resistance
|
||||
|
||||
- Dispersion is only possible if {number of icons per key} <= {number keys in the keypad}
|
||||
- If there are more icons per key than keys, it makes it difficult to phish for a users nkode
|
||||
|
||||
|
||||
## Cipher Keys
|
||||
|
||||
#### attribute key
|
||||
|
||||
- randomly generated array of unsigned integars
|
||||
- array of length {numb of keys} * {number of attributes per key}
|
||||
- xored with ss-attr to give each user a unique
|
||||
|
||||
#### passcode key
|
||||
|
||||
- randomly generated array of unsigned integars
|
||||
- array of length {max nKode length}
|
||||
- xored with final user passcode
|
||||
|
||||
#### set key
|
||||
|
||||
- used to recover users nkode set values
|
||||
- array of unsigned integars
|
||||
- each elemenet in the array is a random number XOR'ed with the set value of the users nKode
|
||||
- so `for set_key_i in user_set_key`
|
||||
`set_key_i = user_passcode_set_i ^ random_set_key_i`
|
||||
|
||||
#### mask key
|
||||
|
||||
- used to recover users nkode set values
|
||||
- array of random unsigned integars
|
||||
|
||||
#### server-side attributes (ss-attr) and sets (ss-set)
|
||||
|
||||
- Each icon has a server side attribute.
|
||||
- The icon and the ss-attr are indexed to the same place in an array.
|
||||
- The dispersion and shuffle operation are applied to the index array and the index array is applied to the icon and ss-attr
|
||||
- ss-attrs are randomly generated permutation of unsigned ints (or byte arrays of any length for extra security)
|
||||
|
||||
### Encipher and Hash nKode Passcode
|
||||
passcode = index values of the selected icons infered in set/comfirm
|
||||
user_attrs = arr_xor(ss_attr, user_attr_key)
|
||||
passcode_attr = [user_attrs[idx] for idx in passcode]
|
||||
|
||||
ciphered_passcode = arr_xor(passcode_attr, user_passcode_key)
|
||||
|
||||
// optional sha256 if ciphered_passcode is more than 72 bytes
|
||||
passcode_digest = sha256(ciphered_passcode)
|
||||
|
||||
hashed_passcode = bcrypt(passcode_digest)
|
||||
|
||||
### Enicphering nKode Set
|
||||
|
||||
nKode mask is used to recover the users nKode
|
||||
1. set_key_i = (set_rand_numb_i ^ set_val_i)
|
||||
2. mask_key_i = mask_rand_numb_i
|
||||
|
||||
passcode = index values of the selected icons infered in set/comfirm
|
||||
// recall ss_set array is an order list
|
||||
set_idx = get_set_value(passcode)
|
||||
user_set_keys = [set_key[idx] for idx in set_idx]
|
||||
user_set_vals = [ss_sets[idx] for idx in set_idx]
|
||||
mask = arr_xor(user_set_val, user_set_keys, mask_key)
|
||||
|
||||
- mask_i = mask_key_i ^ padded_passcode_server_set_i ^ set_key_i
|
||||
- mask_i = mask_rand_num_i ^ set_val_i ^ set_rand_numb_i ^ set_val_i
|
||||
- mask_i = mask_rand_num_i ^ set_rand_numb_i # set_val_i is cancelled out
|
||||
|
||||
#### nKode Validation
|
||||
// set_val_i = mask_i ^ set_key_i ^ mask_key_i
|
||||
// selected_keys the keys the user selects
|
||||
recovered_set_vals = arr_xor(mask, set_key, mask_key)
|
||||
user_keypad = get_user_keypad(username)
|
||||
|
||||
presumed_password = get_pressumed_passcode(user_key, selected_keys, recovered_set_val)
|
||||
|
||||
if is_valid_passcode(presumed_password, hashed_passcode)
|
||||
return LOGIN_SUCCESS
|
||||
else
|
||||
return LOGIN_FAIL
|
||||
|
||||
|
||||
## nKode Login Shuffle
|
||||
|
||||
- After a successful login, the users keypad is shuffled in a two step process:
|
||||
1. the keys are randomly shuffled
|
||||
2. half the sets are randomly shuffled
|
||||
- We've found this works best for xyz reason and we're also working on simulations to find a probablity curve for number of overserveration before an adversery can crack an nkode
|
||||
|
||||
|
||||
## nKode Login
|
||||
|
||||
- When a user request their nkode keypad, the server sends a list of svgs in the order they should be displayed
|
||||
- The Gen2 demo implementation works a bit different it sends the svgs indexed in order from 0-total_numb_of_attr along with an index array for how the svgs should be ordered
|
||||
- this is a legacy from the gen 1 keypad but it helps to make the implemntation more concrete so we'll use this legacy
|
||||
- The frontend organized the svgs into keys and displays them.
|
||||
- The user selects keys for their nkode and their key selection is sent back to the server for validation
|
||||
|
||||
|
||||
## Preventing User Enumeration
|
||||
|
||||
- This isn't applied in the demo application
|
||||
- We can prevent a threat actor from enumerating users.
|
||||
- if a valid email is entered into the login for a user that dne, we can create a ghost keypad and have it behave as if it were a real user.
|
||||
- if there are too many "failed nkode attempts" we lock the non-existing user out.
|
||||
- We can prevent timing attacks by either mocking the real control flow or setting a 1 or 2 sec response delay from the time the login request was recieved thereby completely elimiating timing attacks
|
||||
|
||||
## Renew
|
||||
Renew changes user ciphers, user salt, ss_attr, and ss_set.
|
||||
This is import in the event of a partial database hack or leak.
|
||||
An admin or cron job can run the renew with any frequency (daily, weekly, monthly)
|
||||
Users are aware of this process.
|
||||
Nothing changes for them.
|
||||
|
||||
### Three Step Renew
|
||||
Renew has three phases
|
||||
|
||||
1. Server-Side Attribute Renewal: ss_attr and ss_set values are replaced with new values
|
||||
2. Intermdiate User Renewal: every user goes through an intermediate phase before full Renewal
|
||||
3. Full User Renewal: The user's first successful login completes the renewal. User has gets new salt, and cipher
|
||||
|
||||
#### Server-Side Attribute Renewal
|
||||
|
||||
old_ss_attr, old_ss_set = get_ss_vals()
|
||||
renew_ss_vals() // new randomly generated values
|
||||
new_ss_attr, new_ss_set = get_ss_vals()
|
||||
|
||||
xor_ss_attr = arr_xor(old_ss_attr, new_ss_attr)
|
||||
xor_ss_set = arr_xor(old_ss_set, new_ss_set)
|
||||
|
||||
#### Intermdiate User Renewal
|
||||
|
||||
all_users = get_all_users()
|
||||
for user in all_users:
|
||||
user.renew = True // This flags the server to complete phase 3, full user renewal
|
||||
user.set_key = xor_lists(user.set_key, xor_ss_set) // recall user.set_key = rand_num ^ old_ss_set. this operation cancels out old_ss_set and replaces it with new_ss_set
|
||||
user.attribute_key = xor_lists(user.attribute_key, xor_ss_attr) // recall user.attribute_key ^ old_ss_attr are the user's nkode ss attributes so when we
|
||||
|
||||
#### Full User Renewal
|
||||
|
||||
After a successful login user keys are reset as if the user was signing up for the first time
|
||||
|
||||
|
||||
8
projects/smartdoserx/1.13.26 ActX meeting notes.md
Normal file
@@ -0,0 +1,8 @@
|
||||
- basic auth over https
|
||||
- HL7 spec?: https://www.hl7.org/
|
||||
- andrew Ury is talking about an API. what's the API?
|
||||
- is he building a LIMS?
|
||||
- receive reports through ActX portal?: https://www.actx.com/
|
||||
- Who's Paul Holland from actx?
|
||||
- Is Brooks and Jeremy working together? what does Jeremy do?
|
||||
- EHR https://www.gethealthie.com/
|
||||
@@ -0,0 +1,8 @@
|
||||
- ActX might have LIMS built into it so we
|
||||
- originally thought MUSC would need the LIMS but ActX
|
||||
- MUSC is now just pushing to ActX LIMS/Reporting (it was push and pull)
|
||||
- ActX can host the software
|
||||
- Still thinking about either acquiring or making our own Reporting/LIMS
|
||||
- We want to avoid EHR/EMR because it's expensive
|
||||
- SmartDoseRX needs a great interface that's user friendly (this is likely 2nd/3rd phase)
|
||||
-
|
||||
9
projects/smartdoserx/SmartDoseHub.canvas
Normal file
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"bf02e7ba25a0d338","type":"text","text":"","x":-74,"y":-403,"width":250,"height":60},
|
||||
{"id":"da83ff12da506b28","type":"text","text":"SmartDoseRX Hub\n•SmartDoseRx hub will house the LIMS software to push/pull orders and raw data from the lab.\n\n•Genomic database and reporting software to be housed in SD Hub\n\n•Patient genetics information to be stored in SD Hub\n\n•Claims and clinical outcomes data to be stored in SD Hub","x":-289,"y":-220,"width":680,"height":380}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"87a5830bfad976a7","fromNode":"da83ff12da506b28","fromSide":"top","toNode":"bf02e7ba25a0d338","toSide":"bottom"}
|
||||
]
|
||||
}
|
||||
55
projects/smartdoserx/SmartDoseRX Oct. 10 2025.md
Normal file
@@ -0,0 +1,55 @@
|
||||
## SmartDoseRX Hub
|
||||
|
||||
### Workflows
|
||||
|
||||
### Functions
|
||||
- House LMS to push/pull orders and data from lab
|
||||
### Integrations
|
||||
##### Payor or Plan
|
||||
|
||||
##### Pharmacy Benefit Manager
|
||||
|
||||
##### Retail Pharmacy
|
||||
|
||||
##### Lab
|
||||
|
||||
|
||||
precision molecular
|
||||
https://precisiongenetics.com/solutions/aina/
|
||||
https://precisiongenetics.com/solutions/neuropharmagen/
|
||||
|
||||
eventually own our own LIMS and reporting software and genomics data
|
||||
|
||||
|
||||
Phase 1-2: just getting LIMS and reporting for us
|
||||
|
||||
Things are working in precision molecular. By Jan-Feb they want money
|
||||
|
||||
What do Reports look like?
|
||||
- ActX is doing it right now
|
||||
- We'll license/acquire them
|
||||
- They have a genomic database
|
||||
- They will help the provider with Rx's with genetic efficacy
|
||||
- patients
|
||||
|
||||
Reporting software options:
|
||||
option A: ActX (leaning toward ActX)
|
||||
pros is it's better. it's what we want right now
|
||||
cons they may not be open to selling it to us (what will it cost)
|
||||
|
||||
option B MUSC/ aina:
|
||||
cons it's not as good and only works on a limited number of drugs
|
||||
pros
|
||||
acquisition cost would be a lot less
|
||||
|
||||
Timeline to host LIMS and reporting
|
||||
Start with ovation MUSC. We want to use their LIMS
|
||||
|
||||
there is a company that has infrastructure that's secure/HIPPA (https://www.dcblox.com/)
|
||||
|
||||
Questions for me:
|
||||
- What are they?
|
||||
- How do they work?
|
||||
- How long will it take to get them up and running?
|
||||
|
||||
1
|
||||
32
projects/smartdoserx/high level break down.md
Normal file
@@ -0,0 +1,32 @@
|
||||
Here’s the high-level breakdown: ### Infrastructure Setup
|
||||
|
||||
- Establish AWS account and required services
|
||||
- 20 hours
|
||||
- Ready Week 1
|
||||
|
||||
### Database + Data Model
|
||||
|
||||
- Build foundational data model and database to support patient analytics, real-time alerting, and future AI-driven use cases
|
||||
- 20 hours
|
||||
- Ready Week 2
|
||||
|
||||
### Lab UI
|
||||
|
||||
- Full interface for the lab team: view orders, accession samples, manage billing, upload genetic results, review/signout reports, export aggregate data
|
||||
- Includes collaboration with Jeremy + lab team
|
||||
- 50 hours
|
||||
- Ready Week 4
|
||||
|
||||
### ActX Integration
|
||||
|
||||
- Submit raw genetic data + patient/sample info
|
||||
- Receive PGx report back
|
||||
- 30 hours
|
||||
- Ready Week 5
|
||||
|
||||
### Ordering Provider UI
|
||||
|
||||
- Interface for providers to enter patient demographics, insurance-required fields, sample details, and access completed reports
|
||||
- Includes feedback cycles with early adopters
|
||||
- 60 hours
|
||||
- Ready Week 8
|
||||