Re: Possible Security and Privacy Next Steps

Or we extend VehicleError to include classic

user token/credentials invalid
vehicle token/credentials invalid
device token/credentials invalid (where device is e.g. a component or group
of components e.g. in a vehicle)
organisation token/credentials invalid

user details invalid
vehicle details invalid
device details invalid
organisation details invalid

user forbidden
vehicle forbidden
device forbidden
organisation forbidden

etc?

*Kevin Gavigan BSc, MSC, PhD, MCP, MCTS*
*Software Architect*
*Connected Infotainment*
*Electrical, Electronic and Software Engineering (EESE)*
Jaguar Land Rover


*Mobile: 07990 084866*
*Email:* kgavigan@jaguarlandrover.com

*Office address:*
GO03/057 • Building 523, Gaydon • Maildrop: (G03)
Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR

On 27 October 2015 at 16:02, Paul Boyes <pb@opencar.com> wrote:

> Hi
>
> As to yesterday's discussion, I think we should put effort for releasing
> Vehicle APIs on schedule as the principal purpose. For this purpose,
>
> * We may have to omit 'set-api' from V1
> * V1 spec should rely on OS security framework instead of on-going web
> solutions because we cannot control these schedule.
> * Security & privacy consideration doesn't have to be in spec but should
> be anywhere, e.g., as a BG/WG note. This will be required in the review
> process.
>
> Regards,
> Junichi
>
> Paul J. Boyes
> --------------------------------
> Mobile:   206-276-9675
> Skype:  pauljboyes
>
>
>
>
> On Oct 27, 2015, at 12:33 PM, Gavigan, Kevin <kgavigan@jaguarlandrover.com>
> wrote:
>
> Hi Ted,
>
> That's great, thanks,
>
> >> we should review the various use cases and attack vectors.
>
> Completely agree and believe we should use these to develop a Threat Model
>  (focussing on the API and its use), as the type of attacks and their
> mitigations will inform what secure implementations of the spec would need
> to address.
>
> It wont be perfect, and in fact implementors will need to continually
> review, revise and add to it as new threats and types of attack are
> identified, but it will help us think about what the security model will
> need to achieve in a more organised way.
>
>
> *>> If Set/Get/Subscribe/Unsubscribe fails because of a security problem
> what are the detailed error codes. *
>
> Believe we need a high level view of how we are assuming security might be
> implemented. For example, if there are authentication or authorisation
> errors, will these be handled using HTTP 401 and 403 errors?
>
> Then if this is the case, more specifically, believe we should define
> common error codes that are returned to help ensure that this behaviour is
> consistent across different implementations.
>
> For example, believe we would need to define the following error codes for
> a HTTP 401
>
> user token invalid
> vehicle token invalid
> device token invalid (where device is e.g. a component or group of
> components e.g. in a vehicle)
>
> So would return a 401 if request should be retried after
> user/vehicle/device has renewed its access token.
>
> For cases where the information in the request will never succeed (unless
> something else changes e.g. invalid VIN is passed, user does not have a
> subscription and needs to pay for one before authorised request can succeed)
>
> HTTP 403 Forbidden
>
> user details invalid
> vehicle details invalid
> device details invalid
>
> etc (need to add other cases)
>
> Regards,
>
> Kev
>
> *Kevin Gavigan BSc, MSC, PhD, MCP, MCTS*
> *Software Architect*
> *Connected Infotainment*
> *Electrical, Electronic and Software Engineering (EESE)*
> Jaguar Land Rover
>
>
> *Mobile: 07990 084866 *
> *Email:* kgavigan@jaguarlandrover.com
>
> *Office address:*
> GO03/057 • Building 523, Gaydon • Maildrop: (G03)
> Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR
>
> On 27 October 2015 at 11:50, Ted Guild <ted@w3.org> wrote:
>
>> I propose in addition to repeated iteration through the three steps
>> (list use cases, review in detail identifying attacks vectors, derive
>> requirements) as Junichi recommended we need to consider additional next
>> steps.  Here are few that occur to me and for all we should survey other
>> groups at W3C who may have approached similar problems so that we can
>> leverage or learn from.
>>
>> Access Control Mechanism
>>
>> There will be inter-process security restrictions imposed by the
>> operating system.  There is also a need to be able to do similar in the
>> web runtime.  For both it is beneficial to have granular access control
>> on our data spec.  This may be a separate document.  We discussed
>> perhaps a tiered approach and it should allow for implementers to define
>> their preferred different privileged tiers and attributes at that
>> tier.
>>
>> Best Practices for Web Runtime in IVI
>>
>> Since the web runtime will have external interactions we should review
>> the various use cases and attack vectors.  This is not directly related
>> to our specifications but the environment app written against these
>> specs will be operating in so most likely a Best Practices document.
>> Mitigating these concerns are more likely going to be from enforcement
>> systems in the operating system although some elements may be in the web
>> runtime itself.  A sample possible mitigation technique could be for the
>> OS to require all external web site/service interactions to go through a
>> proxy server that manages certificates of sanctioned sites and does data
>> sampling for integrity checks.
>>
>> Entity preferences profile
>>
>> For individual users, owners and applications to be able to define
>> personal, payment, vehicle and other information.
>>
>> --
>> Ted Guild <ted@w3.org>
>> W3C Systems Team
>> http://www.w3.org
>>
>
>
>