ECSS Communications — Security (space-systems/ecss/e50-security)

Use when the data a communication system carries has to be protected in proportion to its sensitivity, per ECSS-E-ST-50C clause 5.8.3 — which services each flow actually gets, what they cost every frame, and how long a key survives the traffic it protects.

Domain quick reference

• The four services stop four different attacks and none of them covers another. Integrity detects corruption, authentication says who sent it, replay protection stops a valid old frame being played again, and confidentiality keeps a listener out. A design that encrypts and does not authenticate is open to an attack encryption never addressed.
• Protection is proportional, which makes the requirement a mapping rather than a level. Each sensitivity group names the services it needs, and a heavier group keeps everything a lighter one asked for, so the check is a set comparison per flow and not a single verdict for the link.
• Applying more than a group needs is a cost, not a defect. It belongs in the report as a service beyond the requirement so the overhead it buys is visible, but it never fails the assessment.
• Security overhead is per frame and permanent. The tag, the initialisation vector and the replay counter are charged on every frame for the life of the mission, so the overhead fraction and the payload rate left behind are what a data budget has to use.
• Replay protection has a lifetime, and it is usually shorter than the key's. Once the counter space is exhausted the numbers repeat, and a repeated counter under the same key is exactly the condition replay protection existed to prevent — so the counter width, the frame rate and the rekey interval are one calculation, not three.
• Two different bounds can end a key, and the remedy depends on which one binds. A narrow counter is fixed with more bits; a per-key frame limit from the cryptographic design is not, and saying which bound binds is what makes the finding actionable.

Workflow

1. Describe each flow by name, sensitivity group and declared services. Reject an unknown group or an unrecognised service name rather than passing it through.
2. Grade the ground network separately from the flows it carries. List the security mechanisms it provides so that nobody unauthorised reaches its facilities to command the spacecraft or take its data, and hold each mechanism to naming which of those two it denies. A flow whose services are all present says nothing about an operator console an unauthorised person can reach.
3. Compare the declared services against the group's required set; report present, missing and beyond-requirement separately.
4. Sum the tag, initialisation vector and replay counter into a per-frame security overhead, treating a zero width as an absent field rather than an error.
5. Express that overhead as a share of the whole protected frame and compare it with the allowance under a relative tolerance, so a design landing exactly on the allowance passes on every host.
6. Report the payload rate the link delivers once the frames are protected, which is the figure a data budget needs.
7. Compute the key lifetime as the smaller of the replay counter space and the per-key frame limit, divided by the frame rate, and name which of the two bound it.
8. Compare that lifetime against the time the design has to go without rekeying. Where the counter binds, give the width that carries it; where the key schedule binds, say so instead of widening a counter that was never the problem.

Obligations

Item	Step
ECSS-E-ST-50C Rev.2 5.8.3a	2

Pitfalls

• Treating confidentiality as the whole of security. Encryption says nothing about who sent a frame or whether it has been played before, and a flow that needs authentication is not served by a cipher.
• Grading the link instead of the flows. Sensitivity is a property of the data, so a link carrying routine telemetry and critical commands has two different requirements on it at once.
• Failing a flow for being protected beyond its group. Extra protection costs overhead and belongs in the report, but it is not a defect and reporting it as one drives designs the wrong way.
• Budgeting the link at capacity. Every frame pays its tag, vector and counter, so the delivered payload rate is lower by the overhead fraction, permanently.
• Sizing the replay counter from the frame size. What matters is the frame rate against the rekey interval: a wide counter on a fast link can still wrap under one key, and a wrapped counter under one key ends replay protection.
• Answering an exhausted key lifetime by widening the counter without checking which bound binds. Where the per-key frame limit is the smaller of the two, extra counter bits change nothing at all.

Behavior contract (gate 3)

Sensitivity-group and service-name validation, the per-group service set comparison including beyond-requirement services, the per-frame overhead and its exact allowance boundary, the delivered payload rate, the key lifetime with its binding bound and the integer replay-counter sizing across the power-of-two boundary are exercised by the gate 3 contract test: scripts/test_e50_security.py against scripts/e50_security_logic.py (stdlib unittest, offline). Run: python3 scripts/test_e50_security.py

Compliance

• ECSS standards are freely downloadable (ESA); cite the source and paraphrase per standards-map.yaml.
• compliance: STANDARDS-REF, gated: false.