u/DistinctTradition200

Just got SDVOSB-certified through VetCert earlier this month. First SBIR Phase I going in June 3 on an open topic (no set-aside).

For SDVOSBs who've won Phase I on non-set-aside topics — did you mention the cert in the proposal narrative, and did you feel like it actually moved anything with reviewers? Or is the realistic answer that SDVOSB only does work for you when the vehicle itself is a set-aside, and on open SBIR topics it's basically background noise?

Trying to decide whether to lean into it in the company-capability section or just list it in the cover sheet and move on.

Following up on my provisioning post from last week — appreciated the scar-tissue replies, they shaped what I'm doing next.

Update on the chip side: Trust&GO and TrustFLEX SKUs are sitting at Factory Special Order across distributors right now, so the path forward is bare TrustCUSTOM with my own slot config. Which means I need a reliable benchtop bridge before I lock anything.

MCP2221A is out. The https://www.eevblog.com/forum/projects/atecc608b-usb-breakout/ rounin EEVblog thread (and a few other scattered reports) describe stop-pulse glitches when talking to the ATECC — bridge emits a partial stop condition that the chip interprets as a wake or a sleep at the wrong moment, and you get non-deterministic NACKs on the next transaction. I saw enough of this on my Adafruit-clone unit last week to believe it. Not a clock-speed issue; it's the bridge's I2C state machine.

Pivoting to the FTDI FT260 (UMFT260EV1A dev board, DigiKey has stock). On paper it has an actual I2C engine rather than bit-banging through HID, and the timing should be cleaner for the wake sequence (tWLO ≥60µs, tWHI ≥1500µs) and for post-command polling.

What I'm hoping someone can validate before I commit:

1. HAL story. cryptoauthlib ships hal_linux_kit_hid (MCP2221A-flavored) and hal_linux_i2c_userspace (native /dev/i2c-N). FT260 exposes itself as HID on Linux. Did anyone wire FT260 into cryptoauthlib by writing a thin HAL on top of libft260, or is there a path I'm missing where it presents as a real /dev/i2c device and the userspace HAL just works?
2. Wake sequence handling. Does FT260's I2C engine let you generate the tWLO low pulse cleanly — either by sending to address 0x00 at a reduced clock, or via some explicit "drive SDA low for N µs" primitive? Or do people end up doing the wake from a separate GPIO and only using FT260 for the actual transactions?
3. Clock stretching + post-command polling. ATECC stretches the clock during long ops (GenKey, Sign — up to ~115ms). MCP2221A's stretching tolerance is documented as flaky. Anyone confirm FT260 handles it cleanly at 100kHz, or do you have to poll status with a sleep between attempts?
4. The "if I were starting today" answer. Aardvark and CP2112 came up in replies last week. Aardvark is great but the price tag makes it a hard sell for benchtop provisioning that has to scale to a fixture later. CP2112 — anyone using it with cryptoauthlib in anger, or is it the same HID-bit-bang class of problem as MCP2221A?

Long-term the bridge is going to be an RP2040 acting as a kit-protocol device over USB CDC so I can own the I2C timing entirely. FT260 is the bridge between "right now" and "production fixture." Want to make sure I'm not buying the same problem in a different package.

Context for anyone new: solo founder, SDVOSB, hardware-rooted attestation product. SBIR Phase I window is tight so I'm trying hard to avoid another week-long detour. Will post back with what I find either way.

Looking at the gap between "best practice" and "what people actually ship" for IoT device identity.

Best practice says: every device gets a unique private key, generated inside a secure element (ATECC608, OPTIGA Trust M, SE050, etc.), never extractable, used for mutual TLS to the cloud and for signing telemetry.

What I see in actual products (teardowns, leaked firmware, CVE reports): keys in flash, often shared across a product line, sometimes hardcoded in the binary. Even from companies that should know better.

For people who've shipped IoT products at any scale, what's the actual barrier?

• BOM cost? (608B is ~$0.60 in volume, hard to argue against)
• Provisioning complexity? (this seems like the real answer — getting unique keys into millions of devices on a contract manufacturing line is genuinely hard)
• Just nobody asking for it until after a breach?

Curious whether anyone's using the pre-provisioned variants (TrustFLEX, TrustCustom) and whether that actually solves the provisioning problem or just moves it.

I'm a one-person SDVOSB (service-disabled veteran-owned small business) building out home/office infrastructure for the company. We do cryptographic authentication for physical items — so the NAS will hold things like authentication photos, 3D models, document vaults, dev mirrors of production databases, Git repos, internal services (Gitea, Radicale, Vaultwarden), and offsite-replicated backups. Plus regular small-business stuff.

I want to build once, then upgrade components over time as SDVOSB surplus programs and budget allow. The goal is "minimum full capability now, clear upgrade paths later." I won't be racking it this year, but I might in 2-3 years if the business grows into a real office space.

What I already have:

• G.SKILL Trident Z5 DDR5-6000 32GB kit (U-DIMM, non-ECC)
• Protectli VP2420 running OPNsense
• TP-Link TL-SG2008P managed PoE switch (Omada)
• Dualcomm ETAP-2003 network TAP
• Pi 5 (8GB), Pi 4, Pi Zero, Jetson Nano — all getting jobs in the stack
• Old Dell XPS that'll serve as a Linux app server / Docker host

Planned build:

• TrueNAS Scale
• Intel i3-14100 or i5-14500
• 4-6× 12TB NAS drives (mixed WD Red Pro + Seagate IronWolf Pro), RAID-Z2
• 2× 500GB NVMe mirrored as ZFS special vdev
• 256GB NVMe boot
• Corsair RM650x PSU
• My existing G.SKILL 32GB

The two questions I keep going back and forth on:

Q1: Case — Jonsbo N3 or SilverStone CS381?

Jonsbo N3 is cleaner-looking, sits on a desk/shelf well, 8 hot-swap bays, mITX only. CS381 is uglier but rackmount-convertible (4U), takes mATX which means more board options, also 8 bays.

If I'm not racking for 2-3 years, does the CS381 "futureproofing" actually matter, or do I just buy a new case when I rack? Anyone regret going Jonsbo when they later wanted to rack?

Q2: Motherboard — B760M now, or W680 with IPMI right away?

Option A: ASRock B760M Pro RS (~$130). Works fine with my G.SKILL. Plan would be to swap to W680 later when budget or surplus allows.

Option B: ASUS Pro WS W680-ACE IPMI (~$400). ECC support with non-Xeon CPUs, IPMI for remote console (huge for headless NAS). Buy once.

Option B is $270 more today. My G.SKILL is non-ECC, so I wouldn't get ECC benefit until I also swap RAM later — but the IPMI alone is appealing for a headless box that'll live in a closet.

Has anyone here regretted going consumer board on a serious TrueNAS build? Is IPMI actually worth $270 in real-life maintenance pain saved? Or is "boot it once, set it up right, ignore it for years" the reality and IPMI is overkill?

What I'm trying to avoid:

Buying twice. Redesigning the pool because I started too narrow. Painting myself into a corner with case/board choices that block a sensible upgrade path.

Appreciate any real-world experience on either question. Happy to share more about the rest of the architecture if it changes the answer.

Designing a board with an ATECC608B on a shared I2C bus alongside an EEPROM and a temperature sensor. Three devices, ~8cm of trace total, 3.3V rail.

Standard I2C pull-up math says somewhere between 2.2k and 4.7k for 100kHz at this capacitance. I started at 4.7k and the secure element's wake sequence is marginal — scope shows the rising edge taking ~600ns, which is eating into my timing budget.

Dropped to 2.2k and edges are clean (~150ns rise), wake sequence is reliable, but now I'm pulling ~1.5mA per line when held low, which matters because this is a battery design.

Is there a smarter approach than just picking a compromise value? Considering:

• Active pull-ups (TI has some parts for this but they're spendy)
• Dropping to 50kHz and keeping the 4.7k
• Splitting the bus so the secure element gets its own pair
• bus segment isolation with a TCA9617 or PCA9306. It's the same family of solutions as the active pull-ups but cheaper and more common.

What would you do? Battery life "rough target" is 2 years on a CR2032, so every µA counts, total system draw matters more than the I2C lines alone. but I also can't have flaky crypto operations.

Building a hardware-rooted attestation product, ATECC608B as the secure element. Spent the last week working through provisioning and want to learn from people who've actually shipped this in production, not just got "hello world" working on a breadboard.

What I've already burned hours on:

Adafruit CircuitPython adafruit_atecc library on Pico 2 (RP2350) — short ops work, but gen_key() and ecdsa_sign() both fail with RuntimeError: CRC Mismatch regardless of I2C clock speed (tested 100/400 kHz). Library can't parse 64-byte responses correctly on this platform.

One chip bricked with lock_all_zones() — slot 0 config that the helper produces rejects external-mode Sign with status 0x0F. The chip's fine, the slot config is permanent. Lesson learned: never use high-level "lock everything" helpers.

Microchip's TPDS GUI is Windows-only and needs the DM320118 dev board (currently 3+ month lead time).

Tried Pi 5 + native cryptoauthlib path — got eaten by Pi installer / device tree issues today, abandoned for now.

What I'm asking:

MCP2221A vs alternatives for the USB-to-I2C bridge between a Linux host and the ATECC? I have an Adafruit-clone MCP2221A arriving tomorrow. Anyone running cryptoauthlib over an FT232H, CP2112, Aardvark, or something else in production? Trade-offs you've actually felt?

Chip form factor for provisioning: SOIC-8 in a ZIF socket (provision then transfer to product PCB), or solder it down first and provision in-circuit? I have SparkFun SOIC-to-DIP adapters with the chip soldered — works for prototype but doesn't scale. What does your shop do at 10/100/1000 units?

cryptoauthlib HAL choice: hal_linux_kit_hid (MCP2221A), hal_linux_i2c_userspace (Pi/native I2C), or building your own? Failure modes you ran into?

Slot config: is there a canonical "ECDSA P-256 + GenKey-once + external Sign + no key export" config blob people use, or did everyone roll their own from the datasheet? Specifically interested in which bit causes the 0x0F rejection from lock_all_zones() defaults — would save me re-deriving.

Pubkey readback: does GenKey's response give you a usable pubkey directly, or do you do a separate read afterward?

Things I'm probably not thinking of, please tell me:

Production line stuff (per-unit timing, fixturing, audit logging)

Compliance pitfalls if/when this product chases FIPS or CMMC eventually

Whether Trust&GO or TrustFLEX pre-provisioned SKUs are actually worth it for sub-MOQ orders (or if everyone just provisions TrustCUSTOM in-house)

Anything about NXP SE050 vs ATECC608B if I'm going to regret this chip choice in 12 months

The "I wish someone had told me this before I started" stuff

Context: Solo founder, small business (SDVOSB-certified), shipping to small-batch initially. Not asking for hand-holding — asking what your scarred-from-experience answer is.

Thanks. Will share back what I learn for the next person who hits this.

Looking at the gap between "best practice" and "what people actually ship" for IoT device identity.

Best practice says: every device gets a unique private key, generated inside a secure element (ATECC608, OPTIGA Trust M, SE050, etc.), never extractable, used for mutual TLS to the cloud and for signing telemetry.

What I see in actual products (teardowns, leaked firmware, CVE reports): keys in flash, often shared across a product line, sometimes hardcoded in the binary. Even from companies that should know better.

For people who've shipped IoT products at any scale, what's the actual barrier?

• BOM cost? (608B is ~$0.60 in volume, hard to argue against)
• Provisioning complexity? (this seems like the real answer — getting unique keys into millions of devices on a contract manufacturing line is genuinely hard)
• Just nobody asking for it until after a breach?

Curious whether anyone's using the pre-provisioned variants (TrustFLEX, TrustCustom) and whether that actually solves the provisioning problem or just moves it.

Building a data logger that cryptographically signs each reading at the point of capture, so downstream systems can verify the data wasn't modified after the fact. Use case is environmental monitoring where data integrity matters for compliance.

Architecture:

• Sensor reads → MCU buffers
• MCU hashes the reading + timestamp + sequence number
• Hash sent to ATECC608B for ECDSA-P256 signing
• Signature stored alongside the reading
• Each reading also includes the hash of the previous reading (hash chain), so tampering with any historical record invalidates everything after it

Why the 608B specifically: private key generated on-die and never leaves, so even with full firmware access an attacker can't forge signatures for a different device. The chain structure means even the device operator can't quietly edit history.

Open questions for the hardware folks:

• Sign latency on the 608B is ~50ms per ECDSA operation. For a 1Hz sample rate that's fine; for anything faster I'd need to batch (sign a Merkle root over N samples). Anyone done this in practice?
• Power: signing draws ~14mA peak. On battery, is it worth gating the chip's power rail between operations, or does the wake sequence overhead make that a wash?
• Anyone have opinions on the 608B vs the SE050 for this kind of workload? SE050 has more features but also more attack surface.

Anyone know from experience if there is any type of pen or ink that will leave permanent writing. I have used sharpies and they are very good at leaving writing that is not easily removed, but it can be removed. Eventually i will be etching but This is where i am at for the next couple months.

Working through some chain-of-custody questions and curious how others approach this in practice.

For traditional disk imaging, the workflow is well-established — hash on acquisition, hash on verification, document the tool/version, sign it off. But for ephemeral evidence (memory captures, live network sessions, volatile artifacts), I keep running into the same issue: the moment you capture it, the source state is already gone, so you can't re-verify against the original.

A few specific things I'm wondering:

I've seen some discussion around using cryptographic timestamping services for acquisition timestamps, but curious whether that's actually showing up in casework or if it's still mostly theoretical.

Not looking for product pitches, just want to understand current practice.

Does anyone know what the future of the Q9 plus is?

The Q9 plus split space (not split keyboard), wired, is my keyboard for life right now, or at least that was the plan. I have two and i couldn't imagine life without them. But i am thinking I will need to switch to the korne as this model does not seem to have lasting power.

Suggestions?

If i have to go splitkeyboard route I am going with the Corne, as that one won't be taken away from me based on market demand.

Does anyone know what the future of the Q9 plus is?

The Q9 plus split space (not split keyboard), wired, is my keyboard for life right now, or at least that was the plan. I have two and i couldn't imagine life without them. But i am thinking I will need to switch to the korne as this model does not seem to have lasting power.

Suggestions?

If i have to go splitkeyboard route I am going with the Corne, as that one won't be taken away from me based on market demand.

Credit to u/FEDCONConsulting whose recent post on the past-performance trap got me thinking about this. Their five paths are all correct and probably the right answer for most people. This is a sixth path that worked for me, posted in case it's useful to someone in a similar spot.

The setup: Veteran-owned, technical background, registered the entity (UEI, CAGE, all of it) earlier this year. Standard advice was to chase a small contract or sub on a prime to start building past performance. I went a different direction.

What I did instead:

Spent the registration window building commercial IP and a working product, not bidding. Filed 19 provisional patents on the underlying tech. Stood up the actual infrastructure — backend running in production, public verification endpoint, hash-chained ledger that anyone can audit. Started taking pre-orders from commercial customers.

The bet is that when I do approach a CO or PM, the conversation isn't "please trust a new SDVOSB with no track record." It's "here's a working system that already has commercial traction, owned by a US veteran-owned entity, and here are the patents that say nobody else can do this exact thing."

Why I think this works (when it works):

Past performance gets reframed. Commercial revenue and shipped product is a kind of past performance, even if it's not contract past performance. For agencies buying through simplified acquisition or commercial-item authorities (FAR Part 12), this can be enough.

Patents change the procurement math. If your tech is patent-protected and sole-source-eligible, you're not competing on price against five other shops. You're the only legal path to the capability. That's a different conversation entirely.

You stop being a vendor and start being a capability. COs would rather find a contracting vehicle to buy something that already exists than fund development of something that doesn't.

It's risk-symmetric. If government interest never materializes, you still have a commercial business. If it does, you walk in with leverage.

Why this is not for everyone:

Requires real technical IP. If your business is services or commodity products, this path doesn't exist.

Requires runway. I'm doing this on tight runway and it's been brutal — most people would be smarter to take FEDCONConsulting's advice and sub on a prime.

Patent filings are expensive and the provisionals are only good for 12 months. There's a clock.

"Sole source" is harder to achieve than people think. The patent has to actually read on what you're selling, and the agency has to write justification.

The point isn't that this is the right path. It's that the standard "get past performance any way you can" framing assumes you're trying to be a contractor. If you're building something that's actually novel and patent-defensible, you might be better served being a vendor the government has to come to, rather than a contractor competing for their attention.

Curious if anyone else has gone this route — would love to hear how it played out at the CO conversation stage.