Security Issues in Embedded Networking

Goals

The result should be in an "interactive classroom style"

• question and answer breaks
• visual aids
• the text itself
  • independently understandable
  • all diagrams fully labelled and self-explanatory
  • at most 10 single-spaced pages (plain text + eps files)

Content

• What's the problem?
  • securing access to devices no open IP nets
  • (what kind of devices? routers? toasters? other tools?)
    • some devices might have private data (logs of movement, location, etc) that should only be released to the right person
    • some devices might perform moderately dangerous or costly functions, and should be access controlled or logged
• What answers are there?
  • overview: kerberos, secure SNMP, nothing at all, passwords
    • SNMP weak on "control" strong on cheap (low overhead) observation
      • email from people working closely with the new standards who don't think that SNMP is the right tool with which to control everything
      • there are concerns about an SNMP as an international standard specifying a mechanism which isn't exportable, and these concerns have hampered SNMP Security efforts somewhat
    • both standards still in flux
  • what are the limits of each
  • why focus on kerberos anyway?
    • free source -- MIT copyright, not GPL
    • more general purpose
    • yet easy to customize, which this may need
    • easy to set up
    • unix environment tools
    • fits in with existing kerberos environment
• but this is used for mainframe/workstation security...
  • yes, but it was designed for low overhead
  • you're already cross-compiling from there
  • these devices may need to be that secure
• Kerberos in a device, rather than for a device
  • authenticators
  • terminal servers (several companies are already providing terminal servers that support kerberos for outgoing connections)
  • X terminals
  • regular terminals?
  • POS devices? Any kind of signon could be mediated through Kerberos, given an IP or IP-like network.
• How much overhead?
  • code space
  • data space
  • secure storage
  • network traffic
  • computation time (client and server)
  • other special needs (time? filesystem?)
    • on the vxworks board, you could load a value over the serial line at boot time and then reference it via ethernet... not that there is any memory protection once you get on the board, but that's a different issue.
    • you only need 8 bytes for the service key
    • time sync can be replaced with a cache?
• Where can you get it?
  • MIT, Cygnus, DEC, TGV, FTP...
  • in the future, with V5, many more
• Sample application
  • simple server that listens for tcp requests and deals with them. "simple_server" actually shows more of the details of dealing with the connection, so it would be a better example.
  • corresponding client. "simple_client" will do.
  • show use of encryption to transmit data

Raw Data

• Pick a name (mt-i960vx, i960-vxworks)
• Arrange for builds to occur with target-specific path
• Identify the byte order -- set in target file and conf-i960vx.h
• Identify preprocessor defines for the target and use them in osconf.h
• configure
• make depend (ignore errors in compile_et, mkds tools since they're not needed for the target only for the developer)
• build des
  • build with -O2 to ease size estimates
  • replace read_password with an empty file since we're only doing servers, not clients
  • ignore attempts to build verify (try running them later.)
  • build verify, run it (successfully!) on the board.
• build krb
  • first pass covers almost everything that doesn't use sys/file.h.
  • hand create in.h for mk_priv, rd_priv, due to compiler include problem
  • enough of libcom_err built that it can be used
  • ignore command table code
• build an application -- based on vxworks networking code.

Structure

• 1 hour (with breaks for questions)
• 10 pages
• slides

• Divide the paper and talk up differently.
• Put raw tech data in the paper so people can look it up.
• Show the evolution of the product, as it gets ported