Not-a-Fic-a-Day: Securing Security

Remember my last not-a-fic-a-day?

Well, it’s happening again with the world’s latest aggravation, so here, have some less than subtle fictional commentary on that.


From: Metropolitan Security Bureau, United Viridian States

Subject: Isinglass secure dataplaque
I.4 series B
Issue: Court order received by us requiring creation of decryption tool
Priority: Urgent


Ref: Case 411187 (“Request to decrypt user data”)


Customer’s government requested decryption of contents of Isinglass model I.4 secure dataplaque, serial number B1117-1.4-311246, pursuant to a local legal case (see referenced case 411187). As this is not technically possible and against corporate customer data protection policy, standard brush-off sent.


We have at this time received a copy of your court order dated 7123-04-02 requiring us to create and deliver a decryption tool capable of replacing the security firmware on Isinglass model I.4 secure dataplaque serial B1117-1.4-311246.

We have the honor to inform you that since so doing would be a clear violation of our corporate customer data protection policy, which is a contractual matter, we must adamantly refuse to do so at this or any other time.

For the avoidance of doubt, however, we also ask you to be advised that we are in any case incapable of creating such a tool. By design, the security firmware of the Isinglass and other secure terminal equipment, along with all cryptographic keys and other data required by said security firmware, resides within a dedicated (“Secure Enclave”) nanocirc, designed not to permit external update, and enclosed in quantum security mesh which will cause immediate hardware self-destruction if the nanocirc shell is penetrated by any device or other instrumentality capable of modification or observation.

(Updates to the security firmware require physical replacement of the dedicated nanocirc which, consequentially, replaces all cryptographic keys and therefore renders unreadable all data stored on the device unless it has previously been transferred to another device under the control of the previous firmware.)

This design, you will note, was specifically chosen to prevent any of our engineers as individuals, or Aleph Null Systems as a corporate entity, from being coerced into bypassing our customers’ security or creating a tool with which this can be done.

Will ye, nil ye, we can offer you nothing but a petabyte of scrambled bits.

Giljen Diasteros
Senior Security Engineer, Aleph Null Systems


Per standing company policy, since a court order is involved, forwarded to the Legal Division.

Per special company policy SD/412: Coercive Sovereign Liability Management, also forwarded to the Security Division, copy to the Counterforce Liasion Office.

– gd/SSE



5 thoughts on “Not-a-Fic-a-Day: Securing Security

  1. I’m guessing, though, that in their own courts of law, the Imperials would view the refusal to voluntarily provide access to such a device as an aggravating circumstance in itself?

  2. If I’m reading Alastair’s posts right, Imperial society considers ones “stuff,” including one’s personal data, to be as much a part of one’s person as their own limbs.

    The right to be to “secure in one’s own person and papers” (including data) is taken VASTLY more seriously in the Empire than anywhere on this planet.

Comments are closed.