COMP 5407 (Jan-Apr 2022): Authentication and Software Security [A, S]

• 10% Participation. Insightful contribution to class discussions, including last 3 classes. Participate in all classes.
  ------ To allow meaningful contribution to class discussion, students are expected to read designated papers before classes.
• 20% Project 1 (written). Due: 11:59pm Fri Feb 25. Minus 2/20 (10%) per day late. See next paragraph for details.
• 30% Project 2 (written). Due: 11:59pm Fri Apr 15. Minus 3/30 (10%) per day late. See next paragraph for details.
• 40% Reading Reflections (written, 10x4%). Minus 0.5/4 (12.5%) per day late. Due 4:00pm sharp on most Tuesdays (see DETAILED SYLLABUS below).
  ------ The reflections, each worth 4%, are 2-page written reports. They require that students carefully read, understand, and provide views on a designated research paper prior to its discussion in class. The main focus should be original, critical and insightful technical commentary - on the paper's weaknesses and strengths, methodology, motivation, and importance of the results (rather than simply superficial summary). Personal opinions should be included, supported by reasoning and explanations. The grading rubric and more details are here.

• Font size and layout. Use 11pt font and single column text.
• No cut-and-paste. All figures and diagrams must be created by the student; cutting-and-pasting is not allowed in this course. For any figures that you recreate from a source, the caption should state "Figure based on original found at [xx]", where [xx] is a formal reference (see next).
• Formal references. For each cited item in your written submissions, an ending References section should list the following four fields in order:
  1) author name, 2) article title, 3) venue name (e.g., conference or periodical); and 4) publication year (add month for magazine articles, month-day for newspaper and blog articles). For books, replace venue by the publishing company. Page numbers are optional for conferences but expected for periodicals; denote a journal paper in volume 3, issue 2, pages 20-31 as: 3(2):20-31. If an informal article lists no author, use the organization (or as a last resort, domain) name and also as the key for alphabetical sorting (but beware: this is often a signal that you should cite a more authoritative source). When there is no formal "venue" (e.g., an unrefereed manuscript, whitepaper, or blog article), give the URL...keeping in mind that a major purpose of citations (aside from giving credit for ideas and quoted passages) is to provide enough detail for a motivated reader to retrieve the item to cross-check the source. For examples, see the chapter PDFs for the background textbook.
• Grammar and clarity. For this grad course, it is expected that all submitted work is well formatted, proof-read, and free of errors in spelling, grammar, punctuation, etc. Submissions failing to meet this expectation are subject to a deduction of up to 20% of the total available grade, independent of technical content; such failures almost always make the technical content unclear also, further impacting the grade.
• Individual reports. All reports are to be written individually, without collaboration. Students may work with others to understand concepts, but no portion whatsoever of submitted work may be shared. COMP5407 addendum on academic integrity: Beyond other university policies (see below), any submissions including uncited portions originating from someone else are subject to a grade of negative 100%, e.g., for an item worth 20% the maximum course mark would then be 60%. Both students may be penalized if an infraction involves copying from another student. If unsure of expectations regarding collaboration or academic integrity, ask the instructor. Posting any portion of assignments online (e.g., to Chegg, CourseHero, OneClass) is considered academic misconduct. You are never permitted to post, share, or upload course materials without explicit written permission from the instructor.
• Deadlines are strict (any partial day late counts as a whole day), with late penalties as noted in the Grading Scheme above. To avoid lateness due to technical glitches, consider submitting at least one hour before the due date/time.
• Submission mode. Deliverables should be submitted through Brightspace.

• Start readings early. Reading reflections require understanding detailed research papers. This typically requires several readings. To allow time both to comprehend a paper and prepare an original, high quality reflection, begin your readings well in advance of the relevant dates. If you don’t yet have experience reading research papers, advice from one individual is given here: How to Read a Paper.
• Passing grade. While most students typically do well, note that a mark of 70% is required for credit in our grad program.

• Student Academic Integrity Policy. Every student should be familiar with the Carleton University student academic integrity policy. A student found in violation of academic integrity standards may be awarded penalties ranging from a reprimand to a course grade of F or being expelled from the program or University. Examples of punishable offences include: plagiarism and unauthorized collaboration. Information on this policy is found here.
• Plagiarism. As defined by Senate, "plagiarism is presenting, whether intentional or not, the ideas, expression of ideas or work of others as one's own". Reported offences will be reviewed by the office of the Dean of Science. Information regarding typical Faculty of Science penalties and guidelines are found here.
• Unauthorized Co-operation or Collaboration. Senate policy states: "to ensure fairness and equity in assessment of term work, students shall not co-operate or collaborate in the completion of an academic assignment, in whole or in part, when the instructor has indicated that the assignment is to be completed on an individual basis". See the note above on Individual reports, and ask the instructor if you have questions about this.
• For other standard university accommodation policies (Pregnancy Accommodation, Religious Observances, Academic Accommodations for Students with Disabilities (PMC), Sexual Assault Support Services, Accommodation for Student Activities), please see the preliminary course outline for COMP 5407 here.

• Class 1 (Jan 11, PAKE#1) PAKE protocols use passwords to authenticate Diffie-Hellman key exchange.
  Course introduction, overview, expectations; review for PAKE (password-authenticated key exchange).
  Book §4.3, 4.5, 4.8 (review DH, EKE, SPEKE; understand small subgroup attacks); start Project 1.
• Class 2 (Jan 13, PAKE#2)
  [hao2021] (systematization of PAKE protocols). Extra: IETF drafts for OPAQUE and CPace.
• Class 3 (Jan 18, CT#1) Google introduced CT to improve browser-server security (TLS in web PKI).
  * [laurie2014] (Certificate Transparency). Self-review: book §8.5. Extra: RFC 9162 (CT v2 spec; 6962 = v1)
• Class 4 (Jan 20, CT#2) Helpful overview (blog with diagrams): How CT works
  [stark2019] (Does CT break the web?). Extra: [dowling2016] (CT properties), [stark2021] (recent survey).
• Class 5 (Jan 25, OAuth#1) OAuth is widely used for web SSO (single sign-on).
  * [chen2014] (OAuth demystified for mobile). Related extra: RFC 8252 (OAuth for native apps).
• Class 6 (Jan 27, OAuth#2). Note that the formal RFCs are 6749, 6750; and threat model, 6819.
  [fett2016] (OAuth 2.0 security analysis). Extra: [fett2018thesis, §3.1-3.2]; [ghase2018] (single sign-off).
• Class 7 (Feb 1, FIDO#1) The FIDO Alliance promotes a suite of (password alternative) user authentication specs.
  * [lang2016] (Security Keys for FIDO U2F). Extra context: video (5min), longer lucid blog (T. Hunt, 2018).
• Class 8 (Feb 3, FIDO#2) Note: FIDO2 = CTAP + WebAuthn; FDO = FIDO Device Onboard (an IoT spec)
  [feng2021] (FIDO UAF analysis; focus on §2-3). The AppID and Facet Spec v1.2 will help your understanding.
  Extra: [angel2021 (How many FIDO protocols?) + Security Ref v2.1 and other FIDO specs (e.g., CTAP, WebAuthn).
  U2F = universal 2nd factor; UAF = universal authentication framework; CTAP = client to authenticator protocols
• Class 9 (Feb 8, Bluetooth#1) We first look at Bluetooth circa 2007.
  * [kuo2007] (Bluetooth pairing and WPS). Extra: [gehr2004mana] (manual wireless authentication).
• Class 10 (Feb 10, Bluetooth#2) For perspective, we return to very early Bluetooth flaws.
  [wong2005] (brute-force keying attack + use of public key). The extra papers include detailed cryptanalytic attacks.
  Extra: [jakob2001] (early Bluetooth weaknesses), [lu2005] (E0 cipher cryptanalysis), [shaked2005] (PIN cryptanalysis).
• Class 11 (Feb 15, two-factor authentication) FIDO U2F, above, supports 2FA alternatives to SMS.
  * [jover2020] (weaknesses of SMS as a 2nd factor)
• Class 12 (Feb 17, device pairing) Secure device pairing sets up security associations (for authenticated key establishment).
  [suoma2009] (security association taxonomy, analysis). Extra: [chong2014] (device pairing survey, usability comparison)
  
  Other early Bluetooth literature: [blue1999spec], [blue2002white], [gehr2004book], [vaud2005cisc], [lindell2008].
  NIST Guide to Bluetooth Security (2017, with Jan 2022 updates): SP-800-121rev2. Early technical note: [rivertz2005].
  Invited talk (Bluetooth and the Pitfalls of Wireless Protocols, Dec 2020): [payer2020].

• Class 13 (Mar 1: early scanner tool based on lexical analysis). Begin Project 2.
  * [viega2000] (ITS4 static vulnerability scanner). Extra: [nozario2002] (quick background on Flawfinder, RATS).
• Class 14 (Mar 3, memory safety and type safety)
  [veen2012] (Memory errors). Extra: [szekeres2013] (eternal war in memory).
• Class 15 (Mar 8, security development lifecycle)
  * [lipner2004] (Microsoft SDL). Extra: [howard2006book] (same topic),
  compare to: [gasser1988, Fig.4-4 in Sec.4.3] (informal vs formal development process).
• Class 16 (Mar 10, security testing, generic challenges)
  [torabi2016] (Security testing beyond functional tests)
• Class 17 (Mar 15, static analysis to detect C string vulnerabilities)
  * [wagner2000] * (Detecting buffer overruns). While now outdated (like ITS4), this work helps us understand the area.
• Class 18 (Mar 17, fuzz testing #1) Microsoft's SAGE tool significantly advanced fuzzing; based on symbolic execution.
  [godefroid2008] (Whitebox fuzz testing). Extra: [godefroid2012] (a gentler oveview).
• Class 19 (Mar 22, model checker for security properties)
  * [chen2002] (MOPS model checker). Extra: MOPS [chen2004], [schwarz2005]; model checking background [ball2001], [clarke2009].
• Class 20 (Mar 24, fuzz testing #2)
  [mcnally2012] (fuzzing state-of-the-art, circa 2012). Extra: updated state-of-art [godefroid2020].
• Class 21 (Mar 29, Rust #1) Optional intro book (online): The Rust Programming Language.
  * [jung2021] (safe programming in Rust). Extra: [balasub2017] (Rust, beyond safety).
• Class 22 (Mar 31, Rust #2) If in need of a reference manual (online): The Rust Reference.
  [jung2018] (Rustbelt, focus on §2: A tour of Rust). Extra: [jung2020] (Understanding Rust, 2020 thesis)
  
  
• Class 23 (Apr 5. No advance reading is required.) Industrial use of fuzzing is rising sharply.
  The Smart Fuzzer Revolution (2016 talk, 46min, Dan Guido).
  Extra: [manes2021] (2019 fuzzing state-of-art, chronological systematization, classification of fuzzers).
• Class 24 (Apr 7. No advance reading is required.) The AFL fuzzer is heavily used in practice and research.
  But [ionescu] (35min) asserts: teaching everyone to fuzz doesn't fix the root problem.
  AFL pitch + more about (revises older readme and technical notes); successor AFL++ (20min, WOOT'20).
  Extra: [klees2018] (evaluating fuzzers), AFLFast (CCS2016, and update in IEEE TSE). Or: static analysis in practice.
• Class 25 (Apr 12) Class discussion of Project 1 attacks (log4shell, SolarWinds Orion).