It seems to me that a useful alternative or supplement to traditional port-knocking, fwknop, etc, for a system requiring only occasional access, would be to:

  • Set up a one-time pad of keys, and a pre-shared key.
  • Store a copy of that pad and that pre-shared key on the server to be protected, and keep another copy of each to hand.
  • Keep all copies of those keys as private as practicable (this should go without saying!).
  • Arrange for the server to be able to receive SMS (text) messages from a whitelist of telephone numbers, discarding all others.
  • Rate-limit incoming SMSes from each whitelisted number by adding a progressively larger delay before processing.
  • Have the server process the SMSes accordingly:
    • If decrypting the contents of the SMS with the current key from the one-time pad yields a message in a specified format, containing a port number, a protocol, and the pre-shared key, then:
      • Delete the current key from the one-time pad, and make the next key the current key.
      • Send a reply SMS, "OK"; and
      • Permit a new inbound connection to the server to be made on that port under that protocol until either such a connection has been made or a pre-configured timeout (e.g. 5 minutes) has elapsed.
    • Else:
      • Do nothing.

I have two questions:

  1. Does such a system yet exist, preferably in a FOSS form?
  2. Other than, perhaps, unsuitability for use-cases requiring large quantities of inbound connections, what are the flaws in such a system?

2 Answers 2


I'm not aware of anything exactly like what you're looking for. Some close misses:

  1. SMSterm provides a terminal-over-SMS, but with 'minimal authentication'. Free, but looks comatose (last updated 2002, no home page)
  2. Ales-U provides commands over SMTP with some mumbling about 'secure method'. Not free, and swinging a big Patent stick, not the most attractive mating behavior.

I haven't played with either, BTW, that's just a little Google and the like.

I will suggest the following thoughts as regards your question #2:

Think SMTP. Any SMS-space solution going to servers is probably going to involve an SMS-to-SMTP gateway, and a solution designed for SMTP will probably work for you as well.

Size matters. SMS messages are short, so if you're signing or encrypting your commands, it's going to take several messages to get them to the server. The server will need to reconstruct the entire message. This is a disadvantage.

Swimming upstream. Most SMS security-related messages go server-to-client, not client-to-server. In essence, that's because it's harder for someone to intercept messages sent to your phone than it is for them to forge messages from your phone. So the key-based encryption you suggest is necessary, but see my previous point about the problems it causes. And you'll find less solutions because everyone else is swimming the other way.

Port knocking is rare. If you're looking for a solution that does port knocking, you're fishing for a pretty rare species. If you look for a solution that permits authenticated remote commands, you might have better luck.

Less chatter is better. One advantage of your scheme is that it doesn't require back-and-forth, it's a one-way request that is then followed up on with a wider bandwidth connection.

Authentication is the key. Once you have a way to send authenticated commands to a server and have them validated and acted upon, the question of what transport you use becomes an add-on. Solve that problem first, and then you can tack it onto whatever transport (SMS, SMTP, HTTP POST, ICMP ping, Avian carrier) you want to.

Public keys are better. If you're going to try to send authenticated messages, don't screw around with "a one-time pad of keys, and a pre-shared key". Just use certificates to encrypt and authenticate. One-time pads are great except when they're not practical, which is usually.


  • Great stuff; thank you! Just to be clear, an SMS-to-SMTP gateway is not part of the picture: I was thinking, rather, that the server would instead receive SMSes via a GSM modem or suchlike. Commented Dec 1, 2013 at 20:15

Here are some flaws I can think of:

  1. SMS spoofing is trivial (e.g. at work I use an online SMS sending service which lets me set any arbitrary alphanumeric sequence as the sending number), meaning the only security that the whitelisting step is providing is that the attacker must know which numbers are on the whitelist. In a typical scenario such information is probably readily available (most people / corporations do not keep their telephone numbers a secret).

  2. It is not hard to intercept communications to and from a SIM card, meaning anything sent to/from your phone and the server can be read and modified.

  3. One time pads are susceptible to man in the middle attacks. For example, let us say I know in advance what port number and protocol you will be opening (e.g. by observing your previous requests). The next time you send the same request, I can intercept it and replace it with a port number and protocol of my choosing, without any knowledge of your one time pad key.

  4. Using point (1) above, I can launch an effective denial of service attack by spoofing SMS messages from every whitelisted number, to force the rate limiting to take place.

  5. Alternatively, I can achieve denial of service by jamming the signal of the GSM device (either your phone, or the server's GSM receiver).

These are just flaws which popped straight into my head when I read your description. There could be others.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .