Final Review: M-45: chrome.platformKeys API

51 views
Skip to first unread message

David Karam

unread,
May 26, 2015, 11:41:25 AM5/26/15
to apps...@chromium.org, securit...@chromium.org
Dear all,

As part of the enterprise push for ChromeOS, we worked to grant more fine-grained authentication for apps and extensions that cannot rely on the default mechanisms provided by ChromeOS (only TLS-auth of HTTPS for web resources). Third party extensions like custom VPNs for example, make use of EAP-TLS which Chrome OS doesn't expose. 

Through the new chrome.platformKeys API, these apps will have access to functionality such as cryptographic encryption and signing that can be used in implementing a diverse set of authentication schemes.

Given the security concern i.e. allowing a third party app to cryptographically sign requests on behalf of the user, any extension wishing to use this API needs to be white-listed by an admin in the management console.


The public API proposal can be found here. The design doc here.

A brief recap of timeline:

Jan 2015: Launch bug filed.
Feb 2015: API landed in M42 dev.
Mar 2015: Security Survey filled.
Mar 2015: Pulse Secure VPN amended their VPN extension (based off chrome.vpnProvider) using the new API
May 2015: Security comments addressed via added policy (awaiting code review).


Please let us know what you think and if we can proceed to move from dev up into stable.


Best regards,

David Karam

Product Manager

dsk...@google.com


λ Ken Rockot

unread,
May 29, 2015, 2:15:01 PM5/29/15
to David Karam, apps-dev, Security Enamel
I think you're just waiting on a final review from security, yes?

From a platform API perspective, going stable with this LGTM.

To unsubscribe from this group and stop receiving emails from it, send an email to apps-dev+u...@chromium.org.

David Karam

unread,
Jun 1, 2015, 2:59:44 AM6/1/15
to λ Ken Rockot, David Karam, apps-dev, Security Enamel
Thanks Ken.

Landing 460232 will address all security concerns mentioned by preliminary reviewers. We will still need the security bit flipped by a final security review.

Does your LGTM imply that we can flip the AppExt bit? (New here so any pointers would be useful!)

λ Ken Rockot

unread,
Jun 1, 2015, 12:35:19 PM6/1/15
to David Karam, apps-dev, Security Enamel
On Sun, May 31, 2015 at 11:59 PM, David Karam <dsk...@chromium.org> wrote:
Thanks Ken.

Landing 460232 will address all security concerns mentioned by preliminary reviewers. We will still need the security bit flipped by a final security review.

Does your LGTM imply that we can flip the AppExt bit? (New here so any pointers would be useful!)


Yes, flip away

David Karam

unread,
Jun 5, 2015, 10:21:09 AM6/5/15
to Emily Stark, λ Ken Rockot, David Karam, apps-dev, Security Enamel
Hey Emily, thanks for getting in touch.

The API is only available on dev channel (the launch is intended to move it to stable). So that is probably why you are getting the undefined.

The engineer working on this went on vacation and is coming back start of next week. He worked the whole weekend before leaving but couldn't land this final change before leaving and he is in touch with the tech lead and QA about this.

Please keep in mind that this has been in dev for quite some time and we already have a partner (Juniper VPN) who has coded against it, and we really are just trying to tie up the last loose ends.


Regarding UI changes, we simply reused the certificate selection dialog and agreed via design review on the string to be used to make sure the user understands the authentication aspect of granting permission for an app to use a certificate on their behalf.

Cisco VPN wants permanent access to a certificate to authenticate itself on your behalf.

Inline image 1



Please let me know if you have any concerns. We are trying to avoid punting this, so please just catch me on chat, I'll be in the US time zone this week.

On Fri, Jun 5, 2015 at 2:16 AM, Emily Stark <est...@google.com> wrote:
Hi David,

I'm doing a final security review for this API. Do you have any screenshots of the UI changes? I tried the test extension as described in crbug.com/450043 but it didn't seem to work (chrome.platformKeys was undefined).

Also, to clarify, it doesn't look like there's been much movement on the enterprise policy CL (crrev.com/1033513005). Is that going to land before going to stable?

Thanks,
Emily

David Karam

unread,
Jun 5, 2015, 6:34:17 PM6/5/15
to Emily Stark, David Karam, λ Ken Rockot, apps-dev, Security Enamel
Thanks all for helping us push this through before branch point.

On Fri, Jun 5, 2015 at 5:20 PM, Emily Stark <est...@google.com> wrote:
Great, security LGTM assuming the admin whitelisting patch lands before branch.

Wez

unread,
Jun 8, 2015, 1:35:32 PM6/8/15
to David Karam, Emily Stark, λ Ken Rockot, apps-dev, Security Enamel
Sorry, I only just saw this.:-/

"platformKeys" is not a great name for this; it sounds like it might be a keyboard-related API, when it's actually not!

David Karam

unread,
Jun 8, 2015, 2:28:35 PM6/8/15
to Wez, David Karam, Emily Stark, λ Ken Rockot, apps-dev, Security Enamel
Thanks James, appreciate the feedback.

The name refers to cryptographic keys generated off the platform. This is consistent with the already released API chrome.enterprise.platformKeys. We have to be consistent in naming across these two APIs as they are referring to the same underlying cryptographic mechanisms.

Thoughts?

Wez

unread,
Jun 8, 2015, 3:20:14 PM6/8/15
to David Karam, Emily Stark, λ Ken Rockot, apps-dev, Security Enamel
Hi David,

Ah, that's unfortunate, but doesn't sound like there's much we can do about it at this stage.

(FYI the specific issue here is that keys/sequences normally intercepted by the windowing system or shell are often termed "OS keys" or "platform keys", since they're swallowed by the platform, rather than being available to content.) 

Thanks,

Wez

David Karam

unread,
Jun 8, 2015, 3:43:28 PM6/8/15
to Wez, David Karam, Emily Stark, λ Ken Rockot, apps-dev, Security Enamel
It's unfortunate. I actually only joined recently (the work was already done, am just pushing the launch) and it took me some time to get used to the naming so I kind of agree with you that ti's not as intuitive as one would like.

Something like chrome.crypto would have been much more intuitive.

Antony Sargent

unread,
Aug 3, 2015, 1:48:31 PM8/3/15
to David Karam, Wez, Emily Stark, λ Ken Rockot, apps-dev, Security Enamel
Another quick question about this API - an external developer on the mailing list was trying to use it and wondering why it wasn't working, and I believe the problem is that the API is marked as ChromeOS only and this developer was using windows.

We should say something about this in the documentation so that other developers aren't similarly tripped up, and note whether we expect to ever bring it to other platforms or if it will likely always remain ChromeOS only. David, can I assign a bug to you to do this?

Antony Sargent

unread,
Aug 3, 2015, 4:13:21 PM8/3/15
to David Karam, David Karam, Wez, Emily Stark, λ Ken Rockot, apps-dev, Security Enamel
Thanks for the pointer! I actually found where in the doc templates that gets set, and it looks like currently you have to do it manually:


I just created a CL and sent to you: https://codereview.chromium.org/1252963004


On Mon, Aug 3, 2015 at 11:27 AM, David Karam <dsk...@google.com> wrote:
Good catch. I thought such documentation is automatically generated e.g. vpnProvider clearly says Chrome OS Only.

I don't think we will be bringing it to other platforms. The main use case for this was VPN.




David Karam | Product Manager - Chrome for Work | dsk...@google.com | +49 172 280 8110


-- 
Google Germany GmbH
Dienerstr. 12
80331 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

Reply all
Reply to author
Forward
0 new messages