1 / 41

Introduction CS 188 Secure Design for Embedded Systems Peter Reiher January 3, 2011

Introduction CS 188 Secure Design for Embedded Systems Peter Reiher January 3, 2011. Purpose of Class. To teach students about designing secure systems While also considering other important system requirements Functionality Power use Via actual system design. Description of Class.

elu
Télécharger la présentation

Introduction CS 188 Secure Design for Embedded Systems Peter Reiher January 3, 2011

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IntroductionCS 188Secure Design for Embedded Systems Peter ReiherJanuary 3, 2011

  2. Purpose of Class • To teach students about designing secure systems • While also considering other important system requirements • Functionality • Power use • Via actual system design

  3. Description of Class • General outline of class • Prerequisites • Grading • Reading materials • Office hours • Web page

  4. Outline of Class • Not a lecture class • I’ll talk today and Wednesday, but no more lectures • Based on actual design, building, and evaluation of a working system • Using teams of students • Working on assigned projects • Grading based entirely on project elements

  5. So What Will You Learn? • Practical experience in designing systems with security goals • Practical experience in designing systems for embedded platforms • Practical experience in evaluating the power use of systems

  6. How Will It Work? • Teams of students will be assigned to one of five projects • 4-5 students per team • Each team will design and built a working system • Presenting results at the end of the class

  7. Choosing Projects • I will present the five projects later today • Each student will send an ordered list of the projects he prefers • I will assign team members and projects • I’ll listen to particular appeals for team membership • But don’t guarantee I’ll agree to them

  8. Class Activities • Each team will meet with the professor and TA each week • To discuss progress and problems • Teams will create and defend a design • Teams will build to that design • Teams will evaluate their prototype • And present their results

  9. The Design Platform • The Intel ATOM • A popular platform for embedded systems • X86-based • Running the Linux OS • Augmented with special power-measurement capabilities

  10. The LEAP Technology • A power-measurement technology developed at UCLA • By Prof. William Kaiser • Allows unprecedented detailed measurement of power use

  11. The Atom LEAP Platform

  12. Another View

  13. More On LEAP • LEAP allows energy measurement of individual system components • Also allows measurement of power use by particular pieces of code • Controllable by the programmer

  14. What Can You Measure? • CPU power use • Memory power use • Disk power use • Bridge power use • Individual power costs for each component

  15. Energy Calipers • Technique used to measure power costs of particular code • Essentially establishes a start and end point in code for measurement • Gives power use of that code for each measured component

  16. How Does It Work? • An external DAQ samples power use • A clock signal synchronizes the DAQ outputs and the energy calipers • Indicated when the code was entered and exited • Since signals are synchronized, software can assign power to code • Sync granularity is 100 msec

  17. LEAPFrog • LEAP For Repetitive, Organized Gathering • Tool to make experimentation with LEAP easier • Eases running multiple experiments • Better user interface for LEAP • Better formatting of results

  18. Prerequisites • CS111 (Operating Systems) • CS 136 (Computer Security) • If you aren’t familiar with this material, you’ll be at a disadvantage • Talk to me if you want to take this class, anyway • Some knowledge of embedded systems won’t hurt

  19. Teaching Assistant • Peter Peterson • pahp@cs.ucla.edu • No formal recitation sections • But will work closely with students on the Atom LEAPs • Will also work with me on group meetings • Office hours: TBA

  20. Grading • All based on projects • No tests, no homeworks • Project design – 20% • Weekly updates (weeks 2-9) – 40% • Final presentation – 10% • Final report – 30%

  21. Class Format • Few lectures • Today, we talk about the class organization • Wednesday, we talk about evaluation issues • Group presentation in last week • No class meetings in weeks 2-9

  22. Weekly Group Meetings • One hour meeting every week for each group • Some during scheduled hours • Others at mutual convenience • With professor and TA • Attendance is mandatory for all group members

  23. What Happens at the Group Meetings? • Each is a research meeting for that group • To present and discuss design and implementation issues • To update professor on progress

  24. Your Basic Schedule • Week 1: Choose projects • Week 2-3: Design your project and security evaluation of its design • Week 4-7: Implementation of project • Week 8-9: Performance, power, security evaluation of project • Week 10: Present your project

  25. Reading Materials • No required reading materials • There’s one copy of an Atom book that I can share with the class • Some materials related to the projects produced by Peter Peterson • Other materials made available on web site

  26. Office Hours • MW 2-3 • Held in 3532F Boelter Hall • Other times available by prior arrangement • Above and beyond weekly group meetings

  27. Class Web Page http://www.lasr.cs.ucla.edu/classes/188_winter11 • Slides for lectures will be posted there • But there are only two lectures • In 6-up PDF form or Powerpoint • Schedule for group meetings posted there • Materials for using Atom LEAPS there

  28. Why a Class on Secure Software Design? • Software is usually designed to meet some particular need • That need is usually not security-related • But software designed without considering security won’t be secure • And it won’t be easy to fix that

  29. How Do You Learn Secure Design? • Primarily by doing it • There are some principles and approaches that help • But you really only get there through practice • You’re going to get some practice here

  30. The Tricky Thing About Security Design • Again, the primary goal of the software isn’t to be secure • It has to meet functionality goals first • And performance goals • And, for embedded systems, power goals • AND it has to be secure • A classic example of engineering tradeoffs

  31. So What Will You Be Doing? • You’ll be assigned one of five projects • All security related • You’ll design software to solve a problem • You’ll implement that software on the ATOM • You’ll use LEAP to investigate its power properties

  32. The zPad • A fictional project to develop a power-aware highly secure pad computer • Atom is a reasonable hardware platform for it • Linux is underlying software • You will work on important pieces of the system

  33. The Five Projects • CryptoFlex • PowerZone • OffLoading • ElectricSandbox • CryptoDisk

  34. CryptoFlex • Alter crypto used for network transmissions • Based on power status and security posture • Reduce crypto strength when power is low • Prioritize use of crypto among different transmissions to minimize power use • Students build part of system that makes decisions and alters crypto accordingly

  35. PowerZone • Depending on threat level and power status, allow security apps to alter behavior • E.g., firewalls and antivirus software • Delaying scans, prioritizing operations, etc. • General interface for apps to make these decisions • Build general framework and two sample apps using it

  36. OffLoading • Certain security-related operations use a lot of power • E.g., PK authentication • Could offload some operations to a server • Which would require wireless transmissions, which also burn power • When will this win? • Investigate this idea and build framework to test when it wins and loses

  37. ElectricSandbox • Untrusted code can be run in a sandbox to provide greater protection • But at what power cost? • Different sandboxing approaches might have different costs • Design basic sandboxing systems and investigate power costs of running them

  38. CryptoDisk • Data can be protected on disk via full-disk encryption • Which can be done in hardware or software • Which is more suitable for this kind of device? • Build software full disk encryption and investigate performance costs of SW and HW full disk encryption

  39. Common Elements of Projects • All require design • All require software implementation • All require security evaluation • All require performance evaluation • All require energy use evaluation

  40. Security Design • All five projects are security related • But it’s equally important that the systems you build are secure • In design and implementation • Requires attention to secure design and coding techniques • And security evaluations

  41. Evaluating Your Systems • Must evaluate your system for functionality, performance, power, and security • Each is different kind of evaluation • And each particular to the project • But all require experimentation • Some material on that presented next class

More Related