Some Aspects of Security in a Multiprogramming Environment

1. Some Aspects of Security in a Multiprogramming Environment ECEN5043 University of Colorado

2. Favorite sentence in the chapter: “If prevented from picking easy ones (passwords), they will forget them and start writing them down on sticky notes attached to their monitors ...” Been there. Done that. :-)) The above problem will also occur if one is required to change passwords too frequently. (Now how would I know that?!?!) ECEN5043 University of Colorado -- Security

3. Overview • What we won’t cover • Basic Concepts • Topics about Security strongly related to multiprogram systems • Review of cryptography • Process communication • The opportunity of design ECEN5043 University of Colorado -- Security

4. I. What we won’t cover from the chapter • Spy vs. Spy -- virus/antivirus, point/counterpoint • Attacks from inside – except that we will cover: • design principles • programming habits that make it harder to be attacked successfully • User authentication using physical objects or biometrics • Worst security weakness is not addressed in this chapter and most other books on security. ECEN5043 University of Colorado -- Security

5. II. Basic Concepts • Security -- making sure that files are not read or modified by unauthorized persons/programs • includes technical, administrative, legal, social, psychological and political issues • Protection mechanisms • The various means used to ensure security • by the operating system • by some other avenue in the absence of an o.s. • in your cell phone, for example • company procedures ECEN5043 University of Colorado -- Security

6. Basic Concepts : types of threats • Data confidentiality • having secret or confidential data remain so • defining and enforcing who can see what – authorization • authentication– you are who you say you are (still) • identity – I am who I say I am (still) • Data integrity – “the data is what it was” • Unauthorized user or program cannot modify data without owner’s permission • Changing, removing, or adding • System availability • No one can disturb system to make it unusable F. Non-repudiation ECEN5043 University of Colorado -- Security

7. Review of terms: types of intruders • Passive -- read files without authorization • Active -- malicious, unauthorized changes • Casual prying • Snooping by insiders -- personal challenge to break security (also by former insiders) • Financial gain -- theft, blackmail • Espionage -- commercial or military • Virusor worm-- program, not a direct person, (usually) trying to do (usually) general damage via replication ECEN5043 University of Colorado -- Security

8. Basic Concepts: Accidental loss • Accidental loss includes loss of data and/or programs due to • weather, wars, pestilence • hardware or software errors • crash and leave data exposed • corrupt data • human blunder ECEN5043 University of Colorado -- Security

9. Basic Concepts: cryptography • Plaintext -- your original • Ciphertext -- encrypted text that can only be decrypted (deciphered) by authorized people • Security by obscurity -- trying to keep the encryption and decryption algorithms secret • Keys -- parameters to the algorithms that encode and decode ECEN5043 University of Colorado -- Security

10. III.Security Topics & Multiprogram Systems • Avoiding Accidental Loss • Where’s the security related work? • Requirements and design process • Programming habits • Authentication IV. Basic cryptography • Name usage and notation • Digital signatures V. Process Communication VI. Considerations of design details • Protection mechanisms ECEN5043 University of Colorado -- Security

11. III.A. Avoiding Accidental Loss 1. Unintentional loss, not by malicious means 2. Text says “Most of these” can be dealt with by maintaining adequate backups • Backups won’t help certain kinds of data loss such as ...? ECEN5043 University of Colorado -- Security

12. Where’s the security work? • COMET process • Requirements engineering activities • Analysis activities – develop analysis model • Develop design model • Design overall architecture • Initial performance analysis • Component design – Concurrent portion • Performance analysis – refine • Component design – Passive portion • Detailed software design for each subsystem • Refine performance model and analyze ECEN5043 University of Colorado -- Security

13. Where’s the security related activity? (#1) • Requirements engineering activities • Use case model • Relationships between use cases • Package use cases to group large functional areas • Use case narrative descriptions • System test plan • Use Case analysis, part 1 • “Run” tests against use cases ECEN5043 University of Colorado -- Security

14. Where’s the security related work? (#2) • Analysis activities – develop analysis model • Develop domain model • Develop system context model • Develop entity classes static model • Class dictionary • Apply object structuring criteria to structure the system • Classes and objects • Determine high-level subsystems • Add new classes to class dictionary ECEN5043 University of Colorado -- Security

15. Where’s the security related work? (#3) • Analysis activities, continued • Develop dynamic model: for each use case, • Determine which objects participate in the use case • Develop object interaction diagram (sequence or collaboration) • analyze sequence of interactions • analyze information passed between objects • Develop statecharts for state-dependent objects • verify events and actions are consistent with input/output messages of the state-dependent object executing the statechart ECEN5043 University of Colorado -- Security

16. Where’s the security related work? (#4) • Develop design model • Synthesize what you’ve done so far ... produce initial software architecture • Synthesize partial use case based statecharts for a particular object into a complete statechart for that object • Synthesize a collaboration model from the use case based individual collaboration models • Synthesize a static model – class diagram ECEN5043 University of Colorado -- Security

17. Where’s the security related work? (#5) • Design overall architecture • Structure into subsystems using criteria • Define subsystem interfaces • Develop synthesized collaboration diagram for each subsystem • Develop high-level collaboration diagram for whole system • (Design distributed component-based architecture) • Performance analysis ECEN5043 University of Colorado -- Security

18. Where’s the security related work? (#6) • Component design – Concurrent portion • design the concurrent task architecture for each subsystem • apply task structuring criteria • define tasks and their interfaces • modify synthesized coll. diag. by adding concurrency information • document task behavior specs • Performance engineering analysis (more) • RMA • Performance model refinement ECEN5043 University of Colorado -- Security

19. Where’s the security related work? (#7) • Component design – Passive portion • Within each subsystem, define the passive classes • Class interfaces including all operations • Inheritance hierarchies • Design database, if any, and its wrapper classes • Develop class interface specification • Detailed software design for each subsystem • Internals of composite tasks • Details of task synchronization mechanisms • Connector classes that encapsulate inter-task comm • Internal event sequencing logic • Refine performance model and analyze • Write code ECEN5043 University of Colorado -- Security

20. III. Security Topics & Multiprogram Systems • Avoiding Accidental Loss • Where’s the security related work? • Requirements and design process • Programming habits • Authentication IV. Review of basic cryptography • Name usage and notation • Digital signatures V. Process Communication VI. Considerations of design details • Protection mechanisms ECEN5043 University of Colorado -- Security

21. III. B. “Programming” habits • Array bounds checking • Hazop-type review: explicitly check the length of all user-supplied strings before stuffing them into fixed-length buffers • Efficient? (No measurable impact on performance if the code is not accessed frequently) • Worth it? Probably. Depends on requirements for security -- whether stated or not. • Forging pointers – Smart Pointer Pattern ECEN5043 University of Colorado -- Security

22. III. B. Programming habits (bad habits) • Circumvention of access restrictions on private class members • Type casting -- implicitly or explicitly • Stack class checks for stack overflow or underflow (similar to array bounds checking) • System calls with insufficient return error code checks ECEN5043 University of Colorado -- Security

23. III. Security Topics & Multiprogram Systems • Avoiding Accidental Loss • Where’s the security related work? • Requirements and design process • Programming habits • Authentication IV. Review of basic cryptography • Name usage and notation • Digital signatures V. Process Communication VI. Considerations of design details • Protection mechanisms ECEN5043 University of Colorado -- Security

24. III. C. Authentication – Secure Login • Was initially absent and became important in successive generations of mainframes, minicomputers, personal computers, embedded systems • Section 9.3.1 discusses • easy to crack many login name/password combos, especially with the aid of automation • lunacy of publicly readable password files • Therefore, if programs communicate by password, what can you conclude? ECEN5043 University of Colorado -- Security

25. Suggested approaches re logins & passwords • Don’t store the password; transform it first. • Store a one-way transformation • When password is provided by would-be user/process, transform it in the same way and look for match • Don’t store the transformed password; salt it. • append an n-bit random number called the salt with each password. (This changes when the pswd does.) • concatenate password and the salt, transform that • Store the salted, transformed password in an unreadable file that can be accessed by a slow program ECEN5043 University of Colorado -- Security

26. III. Security Topics & Multiprogram Systems • Avoiding Accidental Loss • Where’s the security related work? • Requirements and design process • Programming habits • Authentication IV. Review of basic cryptography • Name usage and notation • Digital signatures V. Process Communication VI. Considerations of design details • Protection mechanisms ECEN5043 University of Colorado -- Security

27. IV. Review of Basic Cryptography • Cryptography tradition -- “What’s in a name?” • There is a tradition to use certain names to indicate certain roles in security scenarios. • Alice • Bob • Carol • Dave • Eve –an eavesdropper • Mallory (or Mal) –a malicious attacker • Sara or Sue –a server ECEN5043 University of Colorado -- Security

28. Cryptography notation • Plaintext, ciphertext, keys, encryption, decryption • C = E(P, KE) How would you read that? • P = D(C, KD) • KA • Kab • Kapriv and Kbpub • E(Kab,M) • {M} Kab • Sometimes the subscripts are written without using subscript format. • A obtains Kbpub • A:B keyname, {Kab} Kbpub • B decrypts with Kbpriv • Now A and B can use Kab ECEN5043 University of Colorado -- Security

29. Keys A. Secret key: both sender and receiver must know the shared secret key B. Public-key: “public” means “published” • distinct keys used for encryption and decryption • given a well-chosen encryption key, it is nearly impossible to discover the corresponding decryption key • the encryption key is public and uses easy operation • sender sends message encrypted with receiver’s public key; only the receiver can decrypt it ECEN5043 University of Colorado -- Security

30. Digital Signatures • To encrypt and decrypt an entire message may be too time-consuming and unnecessary. (The decryption algorithm is usually much more difficult than the encryption one.) • Or: may want to enforce non-repudiation • Hash a document -- result is a single fixed-length number • Alice “decrypts” the number with Alice’s private key, appends to original plaintext document, and sends to Bob. • Bob hashes the plaintext document again. • Bob applies Alice’s public key to the appended number (see why it has to be fixed length?) • Result should be the original hash result -- why? ECEN5043 University of Colorado -- Security

31. Requirements for digital signatures to work • Must use algorithms for which E(D(x)) = x, not just that D(E(x)) = x , • That is, D and E must be commutative • Receiver must know sender’s public key • May need way to distribute public keys such that they cannot be altered -- certificate • Consider a multi-program system in which you don’t want one of the programs to be impersonated and have Mallory (the program) send bogus messages ECEN5043 University of Colorado -- Security

32. III. Security Topics & Multiprogram Systems • Avoiding Accidental Loss • Where’s the security related work? • Requirements and design process • Programming habits • Authentication IV. Review of basic cryptography • Name usage and notation • Digital signatures V. Process Communication VI. Considerations of design details • Protection mechanisms ECEN5043 University of Colorado -- Security

33. V. Process Communication • Authentication • Digital signatures • User interface design issues • Example: user choices appear in lists rather than free-form typing of strings -- can’t overflow parameter buffer or stack • Checking input w.r.t. bounds & buffer over / underflow (filter methods; even in design by contract) • Protection Mechanisms -- See Section 9.6 in chapter • Is writing to and reading from a shared data file safer than passing parameters? ECEN5043 University of Colorado -- Security

34. III. Security Topics & Multiprogram Systems • Avoiding Accidental Loss • Where’s the security related work? • Requirements and design process • Programming habits • Authentication IV. Review of basic cryptography • Name usage and notation • Digital signatures V. Process Communication VI. Considerations of design details • Protection mechanisms ECEN5043 University of Colorado -- Security

35. The Considerations of Design Details • How much security is your responsibility rather than the o.s.’s (if it exists)? • Erase pages, disk space, tape, etc. before allocating them (Note: there is erase and there is erase) • Design the system calls so as not to be confused by unreasonable parameters; design code to deal with any possible return code (including those not yet defined). • Ensure a killed password check is not considered a successful one – defaults to failure ECEN5043 University of Colorado -- Security

36. The Considerations of Design Details -- cont. • Don’t put operating system structures in user space -- e.g. structure containing file name and parameters is passed to the system; system updates the structure while accessing the file • Do not insert trap doors for testing or debugging convenience -- they will be found by the wrong people some day (your ex-employees, for example) • Make the design public; make it as simple as possible • Make the default “no access” -- e.g. killed password check • Check for current authority ECEN5043 University of Colorado -- Security

37. The Considerations of Design -- cont. • Give each process the least privilege possible • Build protection mechanism into lowest layers of the system -- make it simple and uniform • Conduct design reviews with an eye to security from the outset • Choose what is psychologically acceptable* • Design strong boundaries between kernel and user mode, if possible • Separate login passwords for users from that of system administrator ECEN5043 University of Colorado -- Security

38. The Considerations of Design -- cont. • System design that bases updates over the web is risky • Do not require customers to update via attachments to email • Consider redundant file copies for verification • In multiprogram system, do not require one program to execute a program passed to it or found in a directory without authentication • If designing whole environment, allow selectively write-protected areas • If providing a security warning to the user, consider having it make sense to the user (just a suggestion!) ECEN5043 University of Colorado -- Security

39. VI. The Considerations of Design -- cont. • If product uses imported applet-like code, • sandbox • run interpreted code, checking for problems • only accept code from trusted sources • verified by digital signature • Some combination -- see Notes for VI.M. • When product will run in existing environment, MUST understand how the system keeps track of which object belongs to which domain and what actions are permitted (access control). • Else, must design that, simply and uniformly • Resist the urge to provide multiple ways to do the same thing ECEN5043 University of Colorado -- Security

40. The Considerations of Design Details -- cont. Z. Resist the urge to add unnecessary features for stupid reasons -- like this one. :-)) ECEN5043 University of Colorado -- Security

41. References • Hassan Gomaa, Designing Concurrent, Distributed, and Real-Time Applications with UML, Addison-Wesley, 2000, ISBN 0-201-65793-7 • Andrew S. Tanenbaum, Modern Operating Systems, Prentice Hall, 2001, ISBN 0-13-031358-0. ECEN5043 University of Colorado -- Security