---
# System prepended metadata

title: takenverdeling 21/03

---

• Q: Which security services are required (confidentiality, authentication, data-integrity, non-repudiation, etc.)? 
* A: 
	* confidentiality: required
	* authentication: required
	* data-integrity: required, when pricing is updated its important that you recieve the right price.
	* non-repudiation: required
	* No GPS-spoofing: required
	* Privacy: required, we dont want the government being able to store the roads we drove on.
	* System needs to work even without a connection, people can go through tunnels. But, if the person never connects to the server, they would be able to drive for free 24/7, so we should probably have the client ping the server ocassionally. This creates a weird situation where we cant differentiate between a free-rider and someone who jus never turns their car on (todo)

* Other problems:
	* because the government can't know where you are, you would have to request the entire pricing list of every road, if we want these prices to be dynamic and update, say, every 30 minutes, thats a whole lot of data
	* If we update every 30 minutes, every car in belgium would be requesting a lot of data at the exact same time, possibly resulting in denial of service (todo broadcast maybe fine)
	* When we send out a pricing list, we attach a certain set of bits thats the signature of said pricing list, when we pay we attach this signature again and the server can then reject or accept accordingly if our signature is out of date or bogus
	* Theres like 5000 possibilities for physical tampering, but we all consider them out of scope since this is computer science
	* We're probably going to use a sort of system where we have a public/private key pair linked to your license plate. The government will be able to see which license plate the payment is associated with, we do not consider this a con, this is more just a means to detect tax fraud with little privacy concerns.


• Against which attacks should these security services protect the system?
* Turning the connection off in an attempt to freeride
* man in the middle attacks
* replay attacks
* Denial of service (not really doing something against it)
* Packet loss (not really an attack, but a problem nonetheless)





• Which countermeasures have been taken against these attacks? 
* use a TCP connection to avoid packet loss

• What are possible limitations and remaining vulnerabilities of your system? 

• Which concrete security mechanisms (communication protocols, encryption algo- rithm, key lengths, etc.) do you use to implement these security services? Be sufficiently specific in the description of your choice. 

• Which measures have been taken to protect the users’ privacy?

# takenverdeling 21/03
* Celeste & Sebastien (Hubert voor de vrienden) zullen aan de praktische implementatie werken
* Lias, Robbe & Vaast zullen op een latere datum andere taken opnemen momenteel nog onduidelijk.
* Wout is nog altijd zoek.


# Praktische solution
* confidentiality: required #omgezet door lias
    * Private/public key.
* authentication: required
    * Black box krijgt public/private key
    * Probleem: we willen niet dat overheid key pair kent en we willen auto ook kunnen verkopen
    * Solution: private/public key 1 wordt meegegeven met black box. On boot genereer private/public key 2. Black box communiceerd met overheid en public key 2 wordt geencrypted met private key 1. Dit pair kan maar 1 keer gebruikt worden. Garagisten kunnen een nieuw key pair 1 genereren op jou naam adhv de black box te updaten met je ID en ID wachtwoord

* data-integrity: required
    * Digital signature.
* non-repudiation: required #omgezet door lias
    * Timestamp included in digital signature.
* No GPS-spoofing: required
    * We gaan uit van de assumptie dat er niet fysiek met de box wordt getampered.
* Privacy: required, we dont want the government being able to store the roads we drove on.
    * We sturen enkel de som door dat we moeten betalen, en de overheid weet al wie we zijn door public/private key systeem.

* Updated pricing list delivery:
    * Overheid compressie met (insert whatever algoritme)
    * Hoeft niet encrypted: enkel signed, dit bespaart processing power
    * Dit is waarschijnlijk een vrij grote lijst (ongv kilobytes)
    * Maandelijks updated omdat we niet willen dat elke auto in heel belgie elke dag een ganze lijst moet ontvangen en die dingen waarschijnlijk ook niet zo vaak veranderen
    * Payment messages bevatten de Digital Signature van de pricing list die gebruikt werd, zo kunnen we zeker zijn dat we up2date zijn. Overheid weigert als pricing list outdated is.

* Freeriding vs auto die uit staat
    * Om freeriders (of mensen met een kapotte black box hebben en het niet weten) te onderscheiden van autos die uit staan zal de black box weekelijks een ping sturen. Zo kunnen kapotte black boxes opgespoord worden

* Assumptie van bereik.
    * We gaan ervan uit dat iedereen op zn minst wekelijks een beetje bereik heeft.
    * Bereik is echter niet perfect, en we sturen gewoon enkel door als er bereik is.

* extra notes
    * Symmetric encryption als session key over public/private?
    * 