2. Potential adversaries and threats:
Potential threats: Employees reading other employees' paychecks, employees being able
to modify paycheck calculations. We assume that the system for modifying paychecks is
different and connects to the application server.
Potential adversaries: Sniffers on the company's LAN or active attackers spoofing requests
for paychecks.
Since the employee should only access the web page to view and print his salary,
there should be no danger of data modification. (Although poor design that uses the employee's
credentials to authenticate at the mainframe computer could lead to the potential of
data modification on the mainframe).
A simple threat could be a sniffer sitting on the corporate LAN and sniffing employees'
queries. With this configuration the sniffer can see the employees' Credentials, and
abuse them for later queries. The sniffer could passively see the results of the
employees' queries. and build himself a DB of results.
Active attacker could spoof requests for paychecks, even if the employee did not request
them.

3. Security goals:
We want that only the employee will be able to see his paychecks, in short.
* Confidentiality: Only the employee should see his paycheck.
* Authenticaion: The system should provide paychecks data only to known employees.
* Integrity: The paycheck data should be correct.

4. A simple cryptographic protocol, based on secret keys kept on the employee's PC:
* We assume that employee and his PC are paired (employees don't switch PCs).
The employee's PC holds an employee's secret key and a web server's secret key. The
employee will encrypt his request with the server's key (simple, symmetric encryption).
The web server will retrieve the information and send it to the employee using the employee's
secret key (web server knows all secret keys).
This would protect from a passive attacker from watching the employee's paycheck, and will only
allow an active attacker to spoof a request from the employee to the web server but not read
the response.
5. The problem with the above method is the initial key exchange - each new employee's secret
key should be given to the web server. If this exchange is not done in a secure way (e.g. over
the network) than a man-in-the-middle attack can take place. An attacker between the server and
the employee which was able to modify the exchanged keys can read all traffic.
Additional threats are the physical security of the secret keys - Hacking the web server
will allow an attacker to read all paychecks' data sent from the web server.
A solution depending on symmetric encryption will always be vulurnable on the key exchange stage.
-
6. Possible improvements:
 a. Keeping a public key of the web server: An attacker that could still hack into an
employee's PC will be able to exchange the public key and spoof a response. But on other
situations it does not add security.
 b. Keeping the public key in ROM: Will not allow man in the middle attacks.
 c. Adds an extra layer of authentication. A possible attacker (considered an active attacker)
could have used the employee's PC while he was away to see his paycheck. Using a password
will protect from this type of attack. In addition, using the password as part of the encryption
key could add extra security by preventing an attacker that is able to hack the employee's PC
and steal his secret key from using that stolen key.
 d. The secret key is kept on the smart card. This way an attacker needs the physical card to
be able to read the employee's paycheck (deciphering the encrypted server response) instead of
one time access to his PC. In addition, every employee is able to use every PC to check his paycheck.
e. The device can generate passwords for server authenticaion. Using, for example, a hash of the
username, some private key (known only to server and the token) and the time of the day to generate
a number. This number is used for authentication with the server, which will only be able to
calculate it. This can overcome the weaknesses of passwords (some employees will surely write
it down and keep it beneath their keyboards).
f. Will only help to prove the authentication of the request. Will not add strength to the mechanism
(especially not to protect the content returned from the server).