1. Introduction
6. TLS Security
7. WiFi
8. Network
10. Laptop (server) redundancy
11. Data storage on mobile device
12. Conclusion
Architecture is defined as the way the different components of a system fit together to provide a complete and consistent functionality. For a system’s security architecture, ‘complete’ means that there must be no gaps or vulnerabilities. Consistent means that the design philosophies for securing the components must be compatible with each other, so that it yields a seamless and convenient user experience. While completeness is a great goal, in reality, there will always be new vulnerabilities due to ever changing threats. Hence, the architecture must be periodically assessed to verify its adequacy.
Security is a risk management balance between threat avoidance and user convenience. A perfectly secure system is useless if the users find it to be inconvenient. Users will find ways to circumvent security to make their lives easier. The classic example of a poor security is when users write passwords on yellow sticky notes in response to inconvenient rules for password complexity.
Before any design is laid out, it is important to understand the assets being protected and the threats in the environment. For some GMS roles, like Judges, the risk of leaking information justifies measures like data encryption. For other roles, the lower value of the information does not merit a heavy security implementation.
Convenience: The design should be convenient to the tablet and laptop users, and to the administrators of the system.
Administration: Security should be administered by an authorized user. Only Judge Advisors and Lead Robot Inspectors should have administration privileges.
User identification: Each user should have a unique user id. This improves accountability by attributing actions to a specific user. Sharing user ids should be discouraged since we would no longer know who did what. Administrators should not need to know user passwords.
Roles: Each user should be assigned specific roles for an event.
Privacy: Each user’s notes and data should be kept separate and private. Further, for some roles (Judges), no administrator should ever have access to the user’s data.
Access Control: User access to functions and data should be controlled based on their needs. In a role based system, users are assigned specific roles and each role has specific privileges. Data should be shared based on roles.
Auditing: Important transactions should be logged to indicate who did what and when.
Sharing of mobile devices: Tablets may be shared between multiple users with different roles. Data on the tablets should be segregated between users. However, a user's data will be accessible between roles.
BYOD: Users may bring their own devices. Policy may discourage BYOD for some roles (like Judges). However, people protect their own laptops & mobile devices a lot better when it belongs to someone else. This protects the data in the device.
Network security: The network should support all the requirements listed above.
The security layering for data in motion is as follows:
|
Password based authentication |
|
|
Role based authorization |
|
|
TLS/SSL for data encryption |
|
|
WiFi |
MAC Address Filter (Optional) |
|
WPA2 |
|
|
Hidden SSID |
|
The layering for sensitive data in storage on the PC and on tablets is:
|
Password based authentication |
|
OS provided screen lock (Optional) |
|
AES encryption for data storage |
Each user is assigned a unique id. The id is case sensitive and may contain numbers. A user account is set up by an administrator. The account also defines other attributes like the user’s authorized roles, full name, team affiliations, experience level, preferences, availability, etc.
A user account can be in one of 3 states: Active, Disabled, or Reset. Changing the state to Disabled will immediately disallow all access by the associated user. The Reset state will allow a user to login and select a new password. The system will expect the same password for subsequent access. Alternatively, the administrator can set a password for the user.
Though an administrator can manually specify a password for an account, they are encouraged to use the Password Reset process. This process allows the user to configure their own password without sharing it with the administrator.
There currently are no password quality qualification rules, other than the password cannot be blank. This may be changed later.
Passwords are not stored or transmitted in the clear. On entry, the password is extended to a 16 character string before it is hashed using SHA-1. The hashed value is hashed again. This double hashed value is used as an authenticator and is sent with each transaction from the tablets to the server. The server stores this value and uses it to authenticate the user. The single hashed value is used the encrypt data for some roles (Judges). Knowledge of the double hashed value, which is stored on the server, cannot be used to decrypt data.
A user can be authorized to multiple roles. However, they can login as only one role at a time. Authorization decisions are made using the current role. Choosing an unauthorized role during login will result in a generic “authentication failure” message.
GMS allows Match Observer to distribute their notes to interested users. Besides Judges, Robot Inspectors will find this information on ‘on field’ robot performance useful. However, this information may be considered to be sensitive at some venues and its distribution can be limited to specific roles by configuration.
GMS allows certain information to be publicly broadcast to teams. This includes Inspection Status, Robot weights, Inspection Queue position, Judge Interview schedules, etc. Sharing can be controlled by the administrators. A Configuration screen allows this feature to be enabled or disabled, and also allows enabling / disabling the sharing of specific items.
Network traffic can be optionally protected using TLS (SSL). TLS encryption prevents the theft and reuse of the authenticator that is included in each transaction. Larger packets are compressed before they are encrypted.
SSL requires setting up Public Key Certificates. To avoid the expenses of commercial certificates, the system allows the use of local public keys and certificates. A few certificates distributed with the system for frequently used IP addresses.
Certificates must contain the IP address (or DNS name) of the server. This may not be known ahead of time, especially when the venue’s existing WiFi installation is being used. In this case, an appropriate public key and certificate must be constructed while GMS is being set up at the event. The certificate are distributed to each tablet using QR codes. This procedure is fairly easy and detailed in the Quick Start documentation.
WiFi security depends on the event venue. If the venue’s existing WiFi installation is the only option available and it is wide open, then not much can be done and TLS encryption should be used. This is typically the situation at high schools where the event is spread out in multiple areas and it is not easy to wire in a new WiFi network.
A WiFi network dedicated to GMS can be set up. The configuration is discussed in detail in the WiFi setup documentation. When a WiFi network is set up, WPA2 Protected Access will be used. SSID transmission will be disabled. AES-CCMP will be used instead of TKIP. If multiple access APs are used, they will all use the same security settings so that users can roam freely. WiFi Routers can optionally use MAC address filtering to allow only authorized tablets into the network.
All transactions are initiated by tablets. The server does not maintain any client state. A RESTful protocol is used for communications between the tablets and the server. Each transaction includes an authenticator consisting of the userId and the double hashed password. The user identity and role authorization are checked for each transaction.
The server broadcasts an unencrypted UDP packet when new information is available. This triggers tablets to initiate a secure transaction. Each tablet will delay its transaction by a random time to avoid flooding the server.
Reliability is related to security. GMS will be used in venues where WiFi coverage is poor. At times, the tablet may be disconnected from the server. All transactions are saved on the tablet until they are acknowledged. Transactions that cannot be sent due to communications issues will be saved and resent when communications are restored.
When GMS is used for judging, a laptop dedicated for judging will be placed in the secured Judges’ room. Though Judge’s notes are not copied to the laptop, it will contain some sensitive information, like the finalists for various awards. A section of the local storage on this laptop is encrypted using TrueCrypt. This protects GMS information if the laptop is stolen.
Screen lock should be configured on the laptop to lock on no more than 5 minutes of inactivity.
The Judge Advisor, Judge Assistant and Judges can log in to GMS on this laptop. However, only the Judge Advisor role will have the privileges to add or modify user accounts.
A separate laptop will be used for Robot Inspection. Inspection data is not especially sensitive and the laptop storage will not be encrypted. Note that this laptop may contain inspection data from previous events and this data may be attractive for some nefarious teams. The LRI, Inspection Manager and Robot Inspectors can login to this laptop. Only the LRI will have administrative privileges.
The ‘backup’ laptop should be kept in a safe location. As mentioned above, sensitive judging data will not be copied to this laptop.
A ‘backup’ server can be set up. It periodically updates itself (once a minute) from the active servers. If an active laptop dies (or gets stolen) then the backup can be quickly configured to take its place. Re-configuring it only involves changing its IP address and the down time should be less than 10 minutes. No more than 1 minute of data will be lost since that is the update frequency. Note that some sensitive award selection data associated with judging will not be backed up. However, it will be possible to re-create this information from the Judges’ tablets.
Each user’s data on a mobile device is stored in a separate application directory. Data includes the user’s notes, pictures and voice messages.
For some roles (Judges), the data is encrypted with AES. The SHA-1 hash of the user’s password is used as the encryption key. The encrypted data contains a double hashed value, which is checked during decryption to verify that the entered password is correct.
The architecture effectively enforces the policy that Judge’s notes should be destroyed at the end of the event. A Judge’s notes cannot be decrypted without the password. Only the Judge would know that password. When the Judge returns the tablet at the end of the event, they can no longer access their notes (because they don’t have the tablet), nor can anyone else (because they don’t have the password). For even more security, the application directory containing the data should be deleted when the tablet is recycled at the end of the event.
Note that a Judge’s notes will be permanently lost if they forget their password. There is no backdoor mechanism for recovery. The backup copies are also encrypted.
This brief note is intended to show that a wide range of security areas have been addressed in the basic design. It is not intended to contain sufficient technical details needed for a security audit.
© Rajaram Pejaver, April 2014