08 — Defense Telecom

Telecommunications for mission-critical environments

Encrypted satellite links engineered against interception.

NeoSat is a satellite telecommunications program for high-security, mission-critical use. It is communications work — not weapons development — and the methods that make it hard to intercept are described here in principle only.

The premise

A communication is only as secure as its weakest physical surface. NeoSat starts from that fact and works outward.

This domain is satellite telecommunications for environments where a link must not be intercepted, degraded, or quietly observed: mission-critical operations and security forces. I want to be precise about what that means and what it does not. This is the engineering of resilient, confidential communication channels over satellite — moving messages safely. It is not the development of weapons, and nothing on this page should be read that way.

The interesting constraint is that conventional encryption assumes the transport beneath it is merely untrusted, not actively probed at the physical layer. For the contexts NeoSat is built for, that assumption is too generous. So the work spans the whole stack at once: the radio-frequency and satellite hardware, the materials that shield and isolate it, the cryptography that protects the payload, and an architecture where security is the first constraint rather than the last feature.

What follows describes that system in principle. Specific identifiers, parameters, algorithms, and fabrication methods are deliberately omitted. They are withheld as proprietary, and disclosing them would defeat the purpose of building them.

0

satellite carriers operated directly: Iridium, Globalstar, Inmarsat

4th

constellation in R&D — Starlink integration, working from the SpaceX kit

0

disciplines converging at once: RF, materials, cryptography, architecture

US

intended deployment context — mission-critical security communications

The program

NeoSat — a program of Intellicore LLC.

A shielded RF enclosure with a small antenna — abstract, no identifiers.

What NeoSat is

Ultra-encrypted satellite telecommunications, built from the physical layer up.

NeoSat is a program of Intellicore LLC, the United States company where I am co-founder and CTO. It delivers ultra-encrypted satellite telecommunications intended for security forces operating in mission-critical conditions, where the confidentiality and integrity of a link are not optional.

Its two distinguishing ideas are an encryption approach anchored in physical crystals rather than software ciphers alone, and physical isolation: shielded, isolated boards that communicate magnetically inside metallic enclosures engineered against interception. Both are described here only at the level of principle.

  • Program of Intellicore LLC — a registered US company
  • Directed primarily at United States security applications
  • Testing and trials are being arranged
  • Specific methods withheld as proprietary
The concept

An abstract view of the link and its isolation.

constellation ciphertext ciphertext protected node crypto radio plaintext stays inside protected peer radio crypto plaintext stays inside

Diagram — encrypted link, in the abstract

The payload is protected before it ever reaches the antenna.

A simplified, abstract view: a message is encrypted on an isolated stage, handed to the radio stage, and carried over whichever constellation suits the mission. The plaintext never leaves the protected interior; only ciphertext crosses the air.

This diagram is intentionally generic. It shows the shape of the idea, not the implementation.

shielded enclosure — aluminium + Mu-metal-class external field rejected stage A isolated stage B isolated magnetic coupling no exposed interconnect

Diagram — physical isolation, in the abstract

Magnetic coupling inside a shielded metallic shell.

A second abstract view, this time inside the enclosure. Selected stages are physically separated and coupled magnetically rather than through exposed interconnects, while a shielding shell of aluminium and Mu-metal-class metal contains and rejects fields.

Again, generic on purpose: the principle of isolation, with no real geometry, materials grades, or interfaces shown.

Three views

The system, examined from three angles.

Building on the largest constellations already in orbit.

I work directly with the satellite providers that operate the largest constellations available for commercial and institutional links: Iridium, Globalstar, and Inmarsat. Each is approached through its own development kit, so the link layer is built against the carrier's documented behavior rather than against assumptions.

The selection is deliberate. Coverage geometry, latency profile, and link-budget margins differ between constellations, and a communication system meant for mission-critical use cannot depend on a single path. Treating the carriers as interchangeable transports — chosen per mission rather than per habit — is part of the design.

  • Iridium — cross-linked low-earth-orbit mesh, near-global reach
  • Globalstar — bent-pipe architecture for regional, lower-latency links
  • Inmarsat — geostationary capacity for sustained, higher-throughput sessions
  • Starlink (SpaceX) — currently in R&D, developing against the published kit
Posture

Abstract parameters, stated without operational detail.

A high-level posture rather than a specification. Carriers, isolation, and architecture are named; the methods behind them are not.

NeoSat — posture (abstract)

Domain
satellite telecom
Carriers (operated)
Iridium · Globalstar · Inmarsat
Carrier (R&D)
Starlink / SpaceX
Link posture
carrier-agnostic, per-mission
Encryption basis
crystal-anchored, proprietary
Isolation
shielded boards · magnetic coupling
Enclosure
aluminium + Mu-metal-class
Threat posture
interception-resistant by design
Intended context
US mission-critical / security forces
Program status
in development · trials being arranged
Disclosed detail
principles only — methods withheld
The path

From mission framing to controlled trials.

How a NeoSat link comes together

  1. 01 Mission framing Define context, coverage geometry, and threat posture before any hardware decision.
  2. 02 Carrier selection Choose the constellation per mission from the documented behavior of each kit.
  3. 03 Crypto & isolation Bind the crystal-anchored encryption to a shielded, physically isolated board design.
  4. 04 Enclosure build Fabricate the metallic enclosure; route selected stages through magnetic coupling.
  5. 05 Trials Arrange controlled testing toward mission-critical deployment.
The convergence

Why this draws on several disciplines at once.

NeoSat is the clearest case I have of work that no single discipline could produce. The radio and satellite engineering sets the link; the materials engineering shields and isolates it; the applied cryptography protects the payload; and a security-first architecture decides how all three fit together without leaving a seam to exploit.

Holding those four together is the point. A cryptographer handing a spec to a hardware team, who hand an enclosure to a materials shop, lose information at every boundary — and the boundaries are exactly where an interception-resistant system tends to fail. Keeping the whole concept in one head is how the seams close.

01

RF & satellite hardware

Link design and integration across Iridium, Globalstar, and Inmarsat development kits, with Starlink integration in active R&D.

02

Materials & shielding

Enclosure design in aluminium and Mu-metal-class metals, applying magnetic and electromagnetic behavior toward physical isolation.

03

Applied cryptography

Proprietary encryption anchored in physical crystals rather than software ciphers alone — methods withheld as proprietary.

04

Security-first architecture

Threat model, isolation boundaries, and key handling treated as the first design constraint, not a later addition.

This is telecommunications for mission-critical environments — moving messages safely, not building weapons.

On disclosure

A closing note, stated plainly. Everything above is deliberately abstract. There are no real identifiers, no agency names, no operational specifics, and no implementation detail — by design, not by omission.

The encryption algorithms, the crystal-based keying, the enclosure geometry and materials grades, and the isolation interfaces are withheld as proprietary. NeoSat is directed primarily at United States security applications, and testing and trials are being arranged. If your work requires that level of confidentiality in a satellite link, the conversation can go deeper under the appropriate terms.

The constellations

Why several orbits, and not just one.

A link that must not fail cannot depend on a single path. The orbit geometry is part of the security argument, not just the coverage map.

The three constellations I operate sit in different parts of the sky and behave differently because of it. A cross-linked low-earth-orbit mesh routes between satellites and reaches almost anywhere with low latency; a bent-pipe arrangement keeps the path simple over a region; a geostationary footprint holds a fixed view and sustains throughput. None of these is strictly better — each is the right answer to a different mission.

Treating the carriers as interchangeable transports, chosen per mission rather than per habit, means a degraded or contested path is a failover rather than a failure. The point below is conceptual. It shows how the orbits relate, not how any particular link is provisioned, and no real parameters are shown.

LEO mesh — cross-linked GEO — fixed protected node ciphertext only mesh hop bent-pipe GEO link

Diagram — constellation paths, in the abstract

One ground node, several ways up.

A simplified view of the same protected node reaching orbit by more than one route: a cross-linked LEO mesh, a regional bent-pipe hop, and a geostationary path. The link layer chooses among them per mission; ciphertext is all that ever leaves the ground.

Generic on purpose — the figure shows the shape of carrier-agnostic routing, not any real link plan.

Orbit characteristics (abstract)

LEO mesh
cross-linked, near-global, low latency
Bent-pipe LEO
regional, simpler ground path
GEO
fixed footprint, sustained throughput
Selection driver
coverage geometry + link budget
Failover
carrier-agnostic, per-mission
Disclosed detail
principles only — methods withheld
The cipher, layered

What protecting the payload actually means here.

isolation boundary — plaintext stays inside key lifecycle — generation · custody · retirement proprietary cipher crystal-anchored entropy ciphertext layers named — methods withheld as proprietary

Diagram — layered protection, in the abstract

Entropy, cipher, lifecycle, boundary — one stack.

An abstract stack rather than a specification. Physical, crystal-anchored entropy feeds a proprietary cipher; a key lifecycle sits around it; and an isolation boundary guarantees that only ciphertext ever leaves the protected interior. Each layer is named; none is detailed.

I describe the order and the intent of the layers, and nothing more. The algorithms, the crystal selection and conditioning, and the key lifecycle are withheld as proprietary — publishing them would defeat the point of building them.

01

Physical entropy source

Keying material is anchored in physical, crystal-based structure rather than derived from software alone. The principle is stated; the source and conditioning are withheld.

02

Proprietary cipher

A purpose-built algorithm rather than an off-the-shelf library, so the cryptographic state is bound to the hardware it runs on. Parameters are withheld.

03

Key lifecycle

Generation, custody, and retirement of keys are treated as part of the threat model, not an operational afterthought. The lifecycle is withheld.

04

Isolation boundary

Plaintext exists only inside the protected interior. Everything that crosses the air is ciphertext. The boundary is the first design constraint.

The shell

Shielding and isolation, from three sides.

The materials side of NeoSat is where most of the abstraction lives, because it is where the most useful detail would also be the most sensitive. What I can state is general and defensible: any conductor that carries a signal also radiates, and any enclosure that is not deliberately engineered will both leak its own fields and admit external ones. A system meant to resist interception has to treat that as a starting condition.

The three views below describe the reasoning in principle — why the physical layer matters, how materials are chosen for what they do well, and why removing the wire removes the tap. No geometry, grades, treatments, or interfaces appear anywhere.

The physical layer is a real attack surface.

Conventional security treats the transport as untrusted but passive. In mission-critical contexts that assumption is too generous: an exposed bus, a connector, or an antenna trace radiating more than it should can become an interception surface long before the cipher is ever challenged.

Generic, defensible context: any conductor carrying a signal also radiates, and any enclosure that is not deliberately engineered will leak and admit fields. NeoSat treats that physics as a design input rather than an accident to tolerate. The specific geometry and grades are withheld.

  • Radiated emissions treated as an interception surface
  • Enclosure engineered to contain and reject fields
  • Physics treated as a design input, not an afterthought
engineered shell — aluminium + Mu-metal-class protected interior external field rejected external field rejected internal fields contained — geometry withheld

Diagram — field containment, in the abstract

A shell that keeps fields in, and out.

A conceptual cross-section: a protected interior surrounded by a shell of aluminium and Mu-metal-class metal. Internal fields are contained; external fields are rejected at the boundary. The figure is a principle, not a build.

No real geometry, no thicknesses, no layering order — only the idea that the boundary is doing deliberate work.

The program path

Where the work has been, and where it is going.

NeoSat did not start as a product roadmap; it started as four disciplines being held together until they stopped losing information at the boundaries. The progression below is described at a high level, the same way everything else here is — the order of the work, not its operational detail.

  1. Foundations Disciplines converged RF, materials, cryptography, and secure architecture brought under one design intent rather than handed across teams.
  2. Carriers Three constellations operated Iridium, Globalstar, and Inmarsat each integrated against their own development kit, with link behavior built from documented behavior.
  3. R&D Fourth path opened Starlink integration entered active research and development, working from the published SpaceX kit.
  4. Now Trials being arranged Controlled testing toward mission-critical deployment is being organized. Specifics are withheld as proprietary.
The convergence, restated

Four disciplines, one design intent.

It is worth restating plainly, because it is the part most easily lost. NeoSat is not a cipher with an antenna bolted on, nor an enclosure with software inside it. It is the deliberate convergence of radio-frequency engineering, materials, applied cryptography, and a security-first architecture — kept in a single design intent so that the seams between them are not the place the system fails.

Each discipline does a specific job, and the value is in how they reinforce one another. I keep the descriptions abstract for the same reason throughout: the methods and identifiers are withheld as proprietary, and the convergence is precisely what would be most useful to disclose and most damaging to publish.

01

Link sets the channel

RF and satellite engineering decide reach, latency, and link-budget margin per mission across the operated constellations.

02

Materials hold the line

Shielding and isolation keep the physical layer from becoming the weakest surface — described in principle only.

03

Cryptography protects payload

A crystal-anchored, proprietary approach protects the message itself, bound to the hardware it runs on.

04

Architecture closes the seams

Holding all three in one design intent is how the boundaries between disciplines stop being the place a system fails.

Held in one design intent, the boundaries between disciplines stop being the place a system gets intercepted.

Open to the right work

If a link cannot afford to be intercepted, this is the kind of system I build.

If you are holding a problem that doesn't fit inside one field, that is the conversation I want.

NextSelected Work