Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?
share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

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.

HTH!

share|improve this answer
    
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. –  sampablokuper Dec 1 '13 at 20:15
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.