Security, privacy and system integration

1. Begin with the system and what matters

A connected room sensor has several stages: a physical measurement, a controller, a communication path, an application and stored records. Someone might observe the traffic, change a threshold, interrupt delivery or misuse the history after it has been collected. A statement such as “the system is secure” is incomplete until we identify what is protected, against which actions and under what assumptions.

A threat model makes those assumptions explicit. An asset is something of value: the measurement history, control settings, credentials or the ability to receive timely alerts. A threat describes a possible harmful action. A vulnerability is a weakness that could make it possible. Risk considers the likelihood and consequences in the actual setting. A control is a measure intended to reduce that risk.

The opening image is conceptual artwork, not a wiring diagram or evidence that the pictured components have been tested. Use it to locate interfaces and responsibilities. Physical access to the sensor raises different questions from access to an application account, even when both could affect the same displayed value.

2. Confidentiality, integrity and availability

One incident can affect several objectives. Deleting a log may destroy its completeness and make it unavailable. Publishing the same log without permission may leave every byte intact while violating confidentiality. A system that always refuses access may protect disclosure but fail its purpose by being unavailable to legitimate users.

Controls must match the objective. Access restrictions can limit disclosure; authenticated communication can detect certain tampering; backups and redundancy can support recovery and availability. None is a universal substitute for the others. A tested backup also differs from an untested assumption that restoration will work.

3. Identify where trust changes

A trust boundary is a place where information passes between components with different assumptions or authority. Bytes arriving from a device, a browser form or a file should not become trusted program state merely because they arrived through an expected interface. The receiving component needs a contract and checks appropriate to that boundary.

The categories overlap. A convincing message can lead a person to reveal a password, which can then be used to change a configuration. Formatting, logos and fluent language do not establish origin. Verify an unexpected request through a known route rather than treating the message’s own instructions as the verification method.

4. Authentication and authorization answer different questions

Authentication checks a claim about identity or control of an authenticator. Authorization decides what an identified subject may do. Logging in successfully need not permit changing every record or administering the system. A device may be allowed to submit measurements without being allowed to read other devices’ histories.

Least privilege limits an account or component to the authority it needs. A logging process usually does not need broad administrative access. Reducing its permissions limits what can happen if it malfunctions or is compromised. Layered protection places independent checks at useful points; repeating the same faulty assumption in several places does not create independence.

Authentication factors describe different forms of evidence. Two passwords are still the same factor type. A password plus a possession-based authenticator can provide a different combination. Phishing resistance is a further property: not every method described as two-factor prevents a user from being deceived into completing an exchange for an attacker. See NIST SP 800-63B for the detailed identity framework.

5. Password storage is a special problem

A service normally needs to verify a password rather than recover its original text. A suitable password-hashing scheme stores a derived result with a salt and relevant parameters. The salt is not a secret; using different salts prevents equal passwords from automatically having equal stored results. A work factor makes repeated guessing more costly.

A fast general-purpose hash alone is not a complete password-storage design. Nor does adding a salt make a weak password impossible to guess. The distinction matters because an attacker who obtains stored verification data may try guesses without using the normal login interface. Password reuse can also make a compromise at one service affect another. These are design motivations, not an invitation to implement a new password scheme in this lab.

6. Encryption hides content using a key

Encryption transforms plaintext into ciphertext; decryption recovers the plaintext with the appropriate key and scheme. A shift cipher provides an easily reversible classroom example: shifting uppercase letters by three maps DATA to GDWD. There are only 26 possible shifts, so an observer can try every one. It illustrates reversibility, not adequate protection.

Symmetric encryption uses a shared secret between the endpoints. Anyone who obtains the relevant key may gain the corresponding capability. AES is a standardized block cipher, but the algorithm name is only one part of a complete design. Modes, authentication, key establishment and nonce handling matter too. Authenticated encryption combines confidentiality with detection of tampering under the scheme’s conditions.

The practical lesson is to use reviewed protocols and implementations rather than invent a cipher from a classroom example. DES is a historical Data Encryption Standard and is unsuitable for new protection. See the AES specification and the course’s further-study references for algorithm roles.

7. A shared key must reach the right participants

If five people use a separate symmetric key for every pair, they need 5×4/2 = 10 pairwise keys. This simple count shows why key management grows with the communication arrangement. It is not a rule that every real system uses pairwise static secrets: group keys, trusted services and key-agreement protocols create different architectures.

Public-key cryptography separates public and private components. In a public-key encryption scheme, Alice can encrypt to Bob’s public key; Bob uses the corresponding private key to decrypt. Carol knowing the public key does not give her the private key. Public distribution is useful, but Alice still needs evidence that the key really belongs to Bob.

If an adversary substitutes a different public key and Alice accepts it as Bob’s, the mathematical operation can work correctly while protecting the message for the wrong recipient. Trust in the key-to-identity association is therefore part of the system. Public-key encryption, signatures and key agreement are distinct operations, even when related mathematics or algorithms support more than one scheme.

8. A digest summarizes bytes, not their truth

A cryptographic hash maps input bytes to a fixed-length digest. Different inputs can in principle share a digest because the output space is finite; collision resistance means finding such a pair should be computationally difficult for a suitable scheme. Hashes do not decrypt back to an arbitrary original message and do not tell us whether the message is factually correct.

SET,600
SHA-256: 4bcec4fc80e2fafc85591a77d9dca23b5fcdece8de81b0df0d7e8b40d497c061

SET,601
SHA-256: b20cc6738b7f73d9c99d3f0ffdaff1706f96530ac44eb33563ea6d5c2626af0e

These are the digests of the exact UTF-8 message bytes with no final newline. Changing one digit changes the result. Adding a newline also changes the input. Compare the full digest rather than a short prefix. See NIST’s Secure Hash Standard.

A digest detects a mismatch only relative to a reference we trust. If someone can replace both a file and the adjacent digest, computing the digest again does not reveal who made the replacement. A keyed message authentication code or a digital signature can address authenticity within an appropriate design; an ordinary unkeyed hash alone cannot.

9. Signatures bind verification to particular bytes

A signature scheme has signing and verification operations. Signing uses the private key. Verification checks the message and signature against the public key. A valid result supports the claim that the signature corresponds to those bytes under that key; identifying the person or organization still depends on trusting the key association.

The original diagrams use the historical shorthand “encrypt with the private key.” Read it as signing, not a universal definition of digital signatures. Modern schemes are specified as their own algorithms. Likewise, the extra hash pictured on the left of the old verification diagram is not a general instruction to hash every received item twice. See FIPS 186-5.

10. Certificates connect identity claims with keys

A certificate packages a subject’s public key with identity and other information, and an issuer signs that certificate data. It does not contain the subject’s private key. A verifier considers the issuer chain, expected identity, validity interval, permitted usage and applicable status checks under its trust policy.

A certificate signed by somebody is not automatically trusted by everybody. Trust starts from configured anchors and a verification policy. Checking a chain without checking the expected service name can still connect to the wrong service. Dates and key usage also matter; “signature mathematically valid” is only part of validation. RFC 5280 describes the Internet X.509 certificate profile.

A valid server certificate does not prove that every statement on the website is true, that its software has no bugs or that a user is authorized to access every function. Certificates help establish particular identity/key relationships, not general trustworthiness.

11. TLS protects a channel between endpoints

This table is a conceptual overview, not a complete wire trace. TLS has specified messages, transcript checks and multiple modes. Its protected channel does not mean that the application user has logged in: authenticating a server and authenticating a user are separate events. RFC 8446 specifies TLS 1.3.

Protection ends where the channel ends. The receiving application can see plaintext, and stored logs need their own protection. A compromised endpoint can misuse data after decryption. Network metadata may also remain visible. The relevant question is which path and endpoints are covered, not whether a lock symbol appears somewhere in the system.

12. A genuine message can arrive at the wrong time

Imagine a previously valid command to set a threshold to 600. Replaying the exact signed bytes might still pass signature verification even after the intended transaction has finished. Authenticity of bytes does not automatically establish that this is a new authorized action.

Protocols can bind messages to a challenge, session, sequence number or carefully checked time interval. A receiver needs rules for duplicates and stale values. A timestamp by itself is not enough if it can be altered, if clocks are unreliable or if the receiver accepts it without a freshness policy. The protection must cover the relevant context as well as the payload.

Do not infer that every feature of a secure transport protocol has identical replay guarantees. For example, TLS 1.3 early data has special replay considerations. The application’s intended action and retry behavior still need to be designed explicitly.

13. Collecting less can reduce the problem

Security and privacy overlap but are not synonyms. A system might keep detailed room histories confidential while collecting far more personal information than its purpose needs. Ask what is being measured, why it is retained, who can access it and how long the useful purpose lasts.

Replacing a name with a persistent pseudonym does not guarantee anonymity. Linked time, location and behavior can reveal identity or sensitive patterns. A smaller data footprint can reduce exposure, but the adequacy of aggregation depends on context. The NIST Privacy Framework provides further design questions; this section introduces concepts rather than legal advice.

14. Integration starts with contracts between stages

The programming strand combines existing skills: acquire input, validate it, compute a status, form a record and send output to a display or log. The conceptual image shows data flow, not a verified circuit. The transport helper is supplied; this reading does not invent a new serial library.

A contract says what each stage promises and what it requires. A complete-line helper should return an entire bounded record, remove the agreed line ending and provide a valid NUL-terminated C string. It must distinguish a complete line from a partial line, disconnection or oversized input. The parser then checks content. Without this separation, a fragment can be mistaken for a complete measurement.

The range assumes a 10-bit reading for this lesson. Arduino boards and configurations differ, so the range is not universal. A framing layer must also reject embedded NUL bytes rather than silently letting a string parser accept only the prefix. A C string alone cannot reveal hidden bytes after its terminator.

15. The producer emits a simple line

void setup() {
    Serial.begin(9600);
}

void loop() {
    int raw = analogRead(A0);
    Serial.println(raw);
    delay(200);
}

This Arduino sketch samples A0 and prints its decimal value with a line ending. The PC-side helper must agree on the transport settings and strip CR/LF before invoking the parser. The delay supplies a nominal pause; the loop period also includes acquisition, output and other execution time, so it is not an exact 200 ms sampling guarantee.

The sketch assumes an appropriate familiar input circuit and board configuration. It is not a wiring guide or a claim of hardware testing. Consult the Arduino analogRead reference for board-specific behavior. Recitation can reason about the resulting records using saved input without a live board.

16. Validate before changing the output value

int parse_reading(const char *s, int *out) {
    if (!s || !out || !*s) return 0;
    int v = 0;
    size_t n = 0;
    for (; s[n]; ++n) {
        if (n == 4 || s[n] < '0' || s[n] > '9')
            return 0;
        v = v * 10 + (s[n] - '0');
        if (v > 1023) return 0;
    }
    *out = v;
    return 1;
}

The function requires a valid readable NUL-terminated string and a writable int object. It checks null pointers, but cannot validate arbitrary dangling pointers or prove a buffer is terminated. Those remain caller obligations. It rejects empty input, excess digits, non-digits and values outside the chosen range.

The temporary v accumulates the candidate. Only after the whole string passes is *out assigned. Therefore failure preserves the caller’s previous output value. For 700, v becomes 7, then 70, then 700. For 70x, the invalid character triggers rejection before assignment. A leading zero is permitted, so 0007 is accepted; five zeroes are rejected because length is part of the contract.

The calculation is bounded: before another accepted digit v is at most 1023, so one multiplication and addition cannot overflow even the minimum standard range of a C int. The range test then rejects excessive values. This reasoning depends on the chosen small limit; copying the pattern with a much larger limit requires revisiting overflow.

17. Separate valid values from status and errors

int above_threshold(int raw, int threshold) {
    return raw >= threshold;
}

This function performs no input or output. With threshold 600 it returns 0 for 599 and 1 for both 600 and 601. Such a small pure computation is easy to test independently. It assumes raw is already a valid measurement; it does not repeat the framing and parsing responsibilities.

struct Sample {
    unsigned number;
    int raw;
    int high;
};

A rejected record is not a measured zero. Nor is a disconnected input a LOW reading. Retaining the last valid value can be useful, but the interface must indicate that it is old or that a new sample failed. The status of a valid sample and the status of communication are different pieces of information.

18. A valid sample and a saved sample are different claims

int log_sample(FILE *f, const struct Sample *s) {
    if (fprintf(f, "%u,%d,%d\n",
                s->number, s->raw, s->high) < 0)
        return 0;
    return fflush(f) == 0;
}

The function expects a valid writable stream and a valid Sample pointer. It checks formatted output and the flush. Flushing passes buffered data through the C stream interface; it is not by itself a guarantee that data survives power loss. The caller must also check closing the stream. Storage durability is a broader concern than one successful library call.

number,raw,high
1,599,0
2,600,1
3,601,1

The displayed CSV corresponds to accepted inputs 599, 600 and 601 with one rejected bad line between the first two. Since this format writes validated integers, its fields have a simple grammar. A general CSV logger receiving arbitrary text would need correct quoting and additional handling; the assumptions of this small example must remain explicit.

The display can succeed while logging fails, or logging can succeed while a display operation fails. Reporting both as simply “the sensor failed” loses useful information. Identify the stage: input unavailable, invalid record, computation completed or persistence failed. Avoid logging credentials or unnecessary personal information in the error path.

19. Commit the application state deliberately

/* 1: accepted and logged; 0: invalid; -1: stop/error */
int process_line(const char *line, unsigned *accepted, FILE *f) {
    int raw;
    if (!parse_reading(line, &raw)) return 0;
    if (*accepted == UINT_MAX) return -1;
    struct Sample sample = {
        *accepted + 1u, raw, above_threshold(raw, 600)
    };
    if (!log_sample(f, &sample)) return -1;
    *accepted = sample.number;
    return 1;
}

This helper requires stdio.h, stddef.h and limits.h together with the earlier declarations. The caller supplies a valid counter and writable stream. It advances the accepted counter only after logging succeeds, and stops rather than wrapping the unsigned sequence number. The return values distinguish invalid input from an output or sequence-limit failure.

This policy is local to the example. It does not make a file append atomic: a failed write may leave partial output, and a crash between logging and updating the counter can leave ambiguous state. The demonstration stops on an output error. Automatically retrying the same record without a policy could create duplicates. A durable production log needs explicit recovery and retry behavior.

20. Test the boundaries between components

Incremental development reuses Week 7’s principle: integrate one bounded component, observe its result and add the next. First test the parser with saved strings; then threshold boundaries; then formatting; then failure propagation. Only after those responsibilities are understood should the supplied transport be connected.

The parser tests do not test the actual serial helper, and a host compilation does not test a board or circuit. State the scope of evidence. A saved-input run is valuable because it is repeatable, but hardware timing and framing behavior require their own checks.

Calendar Week 13 / Lab 12 consolidates one bounded PC/Arduino exchange and a small log using familiar hardware and transport. It adds no requirement to implement cryptography, a serial library or a new peripheral. The security strand instead helps explain what the integration example does and does not guarantee.

21. Validation supports security but does not replace authentication

Rejecting malformed input prevents a class of mistakes at a boundary. It does not establish who sent an accepted reading, whether a physical sensor was accurate, whether a signed command is fresh or whether a user has permission to change a setting. Each question needs evidence from the responsible layer.

For the same reason, a log entry is not automatically proof of a physical event. Consider how it was produced, which identities and timestamps are reliable and who can modify it afterward. Log only what serves the stated debugging or audit purpose, with retention and access suited to that purpose.

22. Optional: read the original security figures critically

The certificate figure is a historical encoding example. Its algorithm names and fields should not be copied as a current configuration recommendation. The protected-transfer figure uses SSL terminology; contemporary secure transport is discussed here using TLS. It is not a message-by-message TLS 1.3 diagram.

Keep algorithm roles straight: AES is a symmetric block cipher; SHA-256 is a hash; RSA has separately specified encryption and signature schemes; RC4 is neither RSA nor a digital-signature algorithm. A familiar acronym does not tell us whether the surrounding protocol handles keys, authentication and replay correctly.

23. Sources and further study

This reading follows the accepted 67-slide Week 13 deck, preserving all twelve embedded teaching-image components as eleven figures. Original diagrams come from instructor Sets 15, 5 and 16. The connected-sensor and pipeline illustrations are generated conceptual artwork, not tested wiring evidence. The local figure manifest retains source notes and hashes.

• Brookshear & Brylow, Computer Science: An Overview, 12th Global Edition: security, networking and data/social context, especially section 4.5. Historical notation is qualified in this reading.
• NIST SP 800-63B — authentication, factors and password-verifier design.
• FIPS 197: AES, FIPS 180-4: Secure Hash Standard, and FIPS 186-5: Digital Signature Standard — compare purposes before studying algorithms.
• RFC 5280 — certificate profile; RFC 8446 — TLS 1.3. These are optional technical references, not required cover-to-cover reading.
• NIST Privacy Framework — privacy questions beyond confidentiality.
• Arduino analogRead and Serial.println — confirm behavior for the selected board and interface.
• WG14 N1570, public C11 committee draft, for streams, formatted output and integer types; the checked PC examples use C17-compatible features.

For review, draw a boundary around each component of the sensor system. Write one promise beside each arrow and one failure beside each component. Then name the evidence that would justify claiming confidentiality, authenticity, correct parsing and successful persistence. Different claims require different tests.