Skip to main content

Security

This page describes how Arifa is built to be safe, what it assumes, and where its limits are. It comes from the source code and the test suite, not from an outside penetration test.

What Arifa trusts​

  • The Ignition gateway. Anyone who can edit the alarm pipelines, the profile settings or the user source already controls what Arifa does. Ignition's own permissions guard that, not Arifa.
  • Africa's Talking. Arifa trusts what Africa's Talking's API returns over HTTPS, authenticated by the API key.
  • Nothing else. Arifa opens no port and accepts no inbound connection. Every network call is an outbound HTTPS request that Arifa starts. Replies are fetched by Arifa, on a timer, only while a code is waiting. There is nothing on the plant network for an outside attacker to connect to.

How acknowledgement is protected​

A reply acknowledges an alarm only when all of these hold:

  1. It reads as a reply: the keyword or ACK, then exactly four digits.
  2. The code matches one that is currently waiting.
  3. It came from a phone number the alarm SMS was sent to.
  4. It was sent after that SMS, allowing for a small clock difference.
  5. The code has not been used before. A code works once, and expires after Code Valid For, 60 minutes by default.

Guessing a code is not useful on its own, because check 3 must also hold: the sender would already have to be one of the people the alarm went to. The test suite covers a wrong code, a right code from the wrong number, a reply sent before the alarm, and the reuse of a spent code.

People the alarm was sent to are not rate-limited on wrong guesses. They are already trusted, and each guess is an SMS they pay for.

Sender numbers can, in principle, be spoofed at the telecom level. This is true of SMS everywhere, and a module cannot detect it.

The API key​

How the key is protected differs between Ignition 8.1 and 8.3.

On Ignition 8.1, Arifa stores the key in an encoded field, which Ignition encodes with its GatewaySec class. Inductive Automation's Ignition 8.1 SDK documentation says that class uses a default encryption key unless the gateway administrator sets a custom one, with the -DencodingKey startup option. This rests on that documentation. It has not been tested by recovering a key from a real gateway database.

On an 8.1 gateway with Ignition's default settings, anyone who gets a copy of the gateway's internal database, for example from a backup, may be able to recover the Africa's Talking key. This applies to everything Ignition stores this way, not only to Arifa, and Arifa cannot change it.

On Ignition 8.3, the key is stored as an embedded secret. Ignition's Secrets Management encrypts it when the profile is saved, and keeps it out of the shared gateway configuration. The settings also offer Referenced, to take the key from a secret provider. Inductive Automation's own tutorial notes that, in its example, a secret was encrypted with the default encryption key, so the advice below still applies. Follow Inductive Automation's Secrets Management documentation to harden the gateway's encryption.

We recommend that you:

  • on 8.1, set a custom encoding key on the gateway;
  • on both, protect gateway backups as you would a file that holds a live API key;
  • use a separate Africa's Talking account, and so a separate key, for each site.

If a key is exposed, generate a new one in the Africa's Talking dashboard, which replaces the old one, and enter it in the profile.

The key never appears in Arifa's logs or error messages, and no log line contains a full phone number. The test suite checks both.

What else was checked​

  • No third-party runtime libraries. Arifa's core library depends only on the JDK.
  • TLS is not weakened. Arifa uses the JDK's default trust store and hostname checks, and does not follow redirects.
  • The JSON parser is bounded. Arifa's small built-in parser for Africa's Talking's responses limits nesting to 64 levels, so a malformed response cannot exhaust the stack.
  • Releases are signed. Ignition checks the signature when you install, and the certificate thumbprint is published. See Install and verify.
  • Every build and test run happens on a clean machine in GitHub Actions.

What SMS cannot protect​

SMS is not encrypted end to end. Alarm text and reply codes cross the carrier network. Do not put anything in an alarm message that you would not want a carrier to see.

Reporting a problem​

Please do not open a public issue for a security problem. Use GitHub's private reporting instead: in the arifa-sms repository, open the Security tab and choose Report a vulnerability. Include what you found and how to reproduce it.

Only the latest release is supported.