Chromium OS Report Part 1

Login

In the cloud-based environment, we can distinguish the login behavior from locally login in a Chromium OS device and cloud login in the internet (Application in the Internet, such as facebook, twitter, web-based e-mail, etc.). Try to think a scenario that you have the different account name and different password for facebook, twitter, and webmail, separately. That means you should remember these different account names and passwords. Once you forget any password, and then you have to go through a long procedure to receive your password by the service provider. This makes user feel inconvenient. In addition, if user goes through many sites that require authentication, user must type his account name and password every time. We believe this will make user has a very bad experience in the scenario. For this reason, the Chromium OS device would provide a convenient way for user as easy as to log in to device and sites, but not reduce the security of user’s password.

1. Design Philosophy

Figure 1 Design PhilosophyIn this section, we illustrate the design philosophy of the Chromium OS device.

In general, an OS runs in the Internet environment, should care about the security issues and the way for user can easy to use the cloud-based services.1.1 Single Sign On (SSO)

This makes user can use to seamlessly access to cloud-based services.1.2 Security and Easy-to-Use

This mechanism will be designed for security, privacy and easy-of-use.1.3 Without Google Login

This can be separated by that supports OpenID for user to access Google services or the services which are provided by other sites.

2. Objective

Because the Chromium OS device is a cloud-based device which is running in the Network environment, user’s data should be bundled together and to know which device to sync it down to. Initially, Google Chromium OS supports the user needs to log in to the device with a Google account. The other authentication methods are provided in the future, says Google’s Chromium OS Team.

The Google’s Chromium OS Team has defined the device will be able to authenticate the user against Google. That means the service always uses the user’s latest password, even if the user change his password in any time or in any place. Assume that user has logged in online at least once, the user can enable to log in to device when offline.

This device also supports a convenient way which is named SSO for user to

access the services in the cloud. The way allows user just signs his account once, and then the other services do not require authentication. This helps user has a seamlessly cloud environment.Otherwise, user can also opt-in the auto-login with SSO, so that he does not need additional authentication.

In the future, the Chromium OS device also supports alternative authentication system, such as:

1. Give users an SSO experience at OpenID relying parties.2. Give users an SSO experience at sites.

Google’s Chromium OS team is also investigating that allow users to log in to a Chromium OS device using a non-Google OpenID provider and that how to enable 3rd

parties to provide interoperable sync service.

3. Design Highlights

They divide this topic into two phases. The phase 1 is discussing the currently implementation of how to achieve authentication for login. They are using the Google Accounts HTTP(s) API to authenticate users and get the appropriate cookies to log the user in to all Google services by the libcurl which is provided by the Linux PAM module (pam_google) in the device-side.

Once the user has successfully authenticated online, the PAM module caches a mapping between the user and the SHA256 hash of his password. The mapping cache is used to log in to device when the network is unavailable. In that case, no cookies can be acquired. Therefore, we can have the unexpired cookies which is a previous authentication already cached in the Chromium browser session. These cookies can be used once for getting back online.

The login UI is the forked version of SLiM. This software provides theme that users can apply many skins into login UI, so that users can change his personality of user interface. In addition, users can also select the different keyboard layout and locale on login screen or be selectable on the fly.

Unfortunately, the normal Google ClientLogin API is not enough for our need, because the APIs are designed to provide cookies that allow a client application to authenticate to a single Google service. If we want to get the cookies into Chromium after the user’s session has begun, we have to do these steps:

1. Get a Google cookies (https://www.google.com/accounts/ClientLogin)2. Get a one-time use token which is used to authenticate the user to any

service (https://www.google.com/accounts/IssueAuthToken)3. Exchange the token for full set of browser cookies we need to do SSO

(https://www.google.com/accounts/TokenAuth)

In the future, Google’s Chromium OS team will provide other APIs for user to reduce these steps.

Figure 2 The ClientLogin Authorization ProcessFigure 1 show an installed application that wants to get the Google services.

This application can pass the authentication procedure by this workflow. Otherwise, if an installed application wants to get OAuth, it can run through the

following workflow:

Figure 3 The OAuth Authorization Process for Installed AppsWhen we surf in the Internet environment, there may have many attackers. For

security, we have to design a mechanism to prevent the attackers to trick user. Because only root certificate that the login process is willing to trust to identify web servers is the issues Google’s SSL cert, the attackers have to trick Google’s registrar before they trick the registrar who sends the SSL cert for www.google.com.

For the auto-login, it’s not safe for that we cache the user’s password and running it in normal login process. As auto-login is opt-in, this means that user has to log in to Chromium OS device first, and then he can do this action. So this is a web-

based flow that results in the user getting an OAuth token that we cache.Here we can divide this issue into two conditions:1. Online: We store the token in the same encrypted-while-shutdown storage

as we’re using for system settings. If the token exchanging is successful, log the user in. You can reference the Figure 4.

Figure 4 Online Auto-Login2. Offline: If the login process would need to proceed offline, then the

presence of the token is deemed to be enough to allow login to succeed. The Figure 5 explains this scenario.

Figure 5 Offline Auto-LoginThe phase 2 is discussing the information sharing between browser and login

manager. When we would like to share code between them, particularly the network configuration, we can use a tightly restricted version of the browser itself as the login manager. If we don’t want to use the limited version of browser as the login manager, we can instead of the “pipe” to receive Google cookies. It will use some other system-wide IPC technique.

As for logging in to third-party sites for which the user has entered their password already, such behavior will likely tied to a password sync system.

Shutdown & Encrypt token

Login Process would check it(exchanging it for Google cookies)

Log the user in

Shutdown & Encrypt token

Login Process would check it(use the presence of the token)

Log the user in