Question 1: RPC encryption activation timing

Due to the fact that it may take a long time (up to a minute) to get RPC service encryption enabled, and there is no overhead after that, we strongly recommend the proxy enable encryption after the app gets activated and there is at least one RPC that needs protection.

This is concerning. The fact that RPC service encryption may take up to a minute, then any app a user activates would appear to the user to be non-responsive. I feel that this would effectively cripple SDL. It is, of course, the prerogative of the OEM to cripple their own system, but nonetheless, we should avoid that if possible.

I think the option specified by this proposal (3) is the worst option. It would be better to either (option 2) determine if the app needs RPC protection and to get it that protection _before_ the user interacts with it if possible (and if it's possible for multiple apps to do it at the same time), or (option 1) for the app to be functional immediately, up to the point that the protected RPC is needed.

I think that we need to not only consider the technical ramifications of this proposal, but also the user UX ramifications, and that such considerations should be contained within the proposal (e.g. a flow diagram showing the expected user-facing flow).

Question 2: Alternative Encrypted RPC Service

We create a new protected RPC service 12, which is similar to the existing service 10 and service 11. We require all RPC messages that need protection (include requests, responses and notifications) must be transmitted via this new SDL service.

I actually like this alternative quite a bit as it provides better separation and cleaner code. Why was the existing solution chosen over this solution?

Question 3: Apps that don't use the protected RPCs

I don't see a consideration in the proposal for applications that don't use the protected RPCs as seen in OnPermissionChanged. How is a mobile proxy supposed to know that the app does or does not use a particular protected RPC and therefore enable encryption? Is it expected to add a new mobile developer-facing API to ask them if they want to use RPC encryption _if needed_? But even that is inadequate. For example, app A uses SendLocation. Knowing that it's a protected RPC on some systems they turn on useRPCEncryptionIfNeeded. Core tells the proxy that some remote control RPC is protected, but SendLocation _is not_; this would still result in the app being unnecessarily protected.

The only solution I can think of is for the app to be informed, at runtime, of protected RPCs, and for the app to respond with whether they use any of them. This kind of solution would be rather difficult to use.

Let me know if this was covered in the proposal and I missed it, it's quite a large proposal.

joeljfischer on 10 Dec 2018

Question 1: RPC encryption activation timing

Due to the fact that it may take a long time (up to a minute) to get RPC service encryption enabled, and there is no overhead after that, we strongly recommend the proxy enable encryption after the app gets activated and there is at least one RPC that needs protection.

This is concerning. The fact that RPC service encryption may take up to a minute, then any app a user activates would appear to the user to be non-responsive.

When the app moves from NONE to other HMI states (get activated), it just triggers the process to enable the RPC encryption. For the first time, there are some extra steps for the app to finish, this process needs some time. However, at the same time the un-protected RPC shall be still usable. So app shall not be non-responsive if the app does it in a background task.

The first option may cause a delay. Because the app wants to send an encrypted message, but the channel is not ready, it must wait the encryption gets enabled to continue.

The second option looks good to me. But for the case that an app get used once or twice, later the app will get registered every time the device get connected, but it never get activated, enable encryption seems a waste of time to me. But it is acceptable.

In the third option, when an app get activated, it is highly possible the app will use the RPCs that need encryption. It seems the best time to me.

Question 2: Alternative Encrypted RPC Service
I actually like this alternative quite a bit as it provides better separation and cleaner code. Why was the existing solution chosen over this solution?

Personally, I actually like this alternative too. We didn't choose it because it requires a new RPC service. We are afraid of the push back of adding a new service.

Question 3: Apps that don't use the protected RPCs
@joeljfischer I not sure I fully understand your comments.

It is the policy (OEM or agreement between app developer and OEM) to specify which RPC(s) of which app need protection. The app cannot make a decision by itself. Once policy says a RPC for an app need protection, the app must follow the rule. Otherwise the SDL rejects the RPCs.

If the app does not need to protect any RPCs and OEM agrees it, the policy server shall be configured to say the RPCs for the app do not need protection at all.

yang1070 on 11 Dec 2018

Question 2: Alternative Encrypted RPC Service
I actually like this alternative quite a bit as it provides better separation and cleaner code. Why was the existing solution chosen over this solution?

The capability of using an encrypted RPC service already exists in sdl core, I'm not sure if it makes sense to create a new service for the same purpose.

mrapitis on 11 Dec 2018

SDL proxy may restart service 7 with encryption enabled in several situations.

So the app is supposed to disconnect from the HU, reconnect with a new StartService that has the encryption bit set? If that is the case, that will be a very poor UX as hash resumption is not currently implemented into the library and the burden on app developers to do so is extremely high.

I would rather see a new control message that allowed a service to enable encryption that starting a service over.

SDL server updates:

The SDL server needs to support the new parameter in the policy table.

These changes will be both front and and back end changes that will take some time to support. Is the intention to allow an OEM to generally say which RPCs need encryption for all apps, or should an OEM have the ability to control the encryption requirement per RPC per app? The latter is much more complex to implement.

Alternative New Service

I'm torn on this one. I don't like creating a new service just for the sake of encryption when we already have the ability to flag it in the protocol. However, it does make the logic necessary to handle this feature much simpler. In my opinion if my previous comment was addressed (new control message to enable encryption on an established service) that would also simplify the logic.

Question 3: Apps that don't use the protected RPCs

To Joel's question, if an app never intended to use GetVehicleData, but a permission update came through that stated that RPC needed to be encrypted, according to the proposal the app would have to restart the RPC service to align, which creates a poor UX.

No Sample Encryption library Android

I would warn that there is currently no example library of how to build an encryption library for Android. I understand the author stated the "how" is out of scope, but I see that as a concern that should be addressed before this proposal is accepted or implemented.

joeygrover on 11 Dec 2018

So the app is supposed to disconnect from the HU, reconnect with a new StartService that has the encryption bit set?

The app would open service type 7 unencrypted, followed by a request to open service 7 encrypted. After receiving an ACK from the HU for the protected service type 7, the app can freely send encrypted / unencrytpted RPC's at will. (this is functionality built into sdl core today, no disconnect is required).

mrapitis on 11 Dec 2018

SDL proxy may restart service 7 with encryption enabled in several situations.

So the app is supposed to disconnect from the HU, reconnect with a new StartService that has the encryption bit set? If that is the case, that will be a very poor UX as hash resumption is not currently implemented into the library and the burden on app developers to do so is extremely high.

No. The app does not need to disconnect first. The existing unprotected service is still working. We do need a StartService that has the encryption bit set on the existing service. That how it is today. I called it restart, but it is actually not a restart, just enable additional functions.

These changes will be both front and and back end changes that will take some time to support. Is the intention to allow an OEM to generally say which RPCs need encryption for all apps, or should an OEM have the ability to control the encryption requirement per RPC per app? The latter is much more complex to implement.

The goal is for an OEM have the ability to control the encryption requirement per RPC per app or for certain new apps. There will be no change for any existing applications that does not need encryption. It is not that complex as it looks. For example, to require all remote control apps use encryption for remote control RPCs, OEM just need to create a new encryption require remote control group and assign this group the RC apps.

yang1070 on 11 Dec 2018

So the app sends a StartService unencrypted then leaves the service open but sends another StartService with the encryption bit set? I'm not sure that is covered in the protocol spec. The service remains open and each app should only have a single service of a single type, so sending the StartService again seems very strange.

joeygrover on 11 Dec 2018

So the app sends a StartService unencrypted then leaves the service open but sends another StartService with the encryption bit set? I'm not sure that is covered in the protocol spec. The service remains open and each app should only have a single service of a single type, so sending the StartService again seems very strange.

Correct as currently implemented in sdl core and the Android proxy. I believe some of the documentation may need to be updated to reflect this.

mrapitis on 11 Dec 2018

@yang1070 The update to the policy server is complex for per app control of RPC per encryption requirement. While the policy table seems straightforward, enabling such control into a UX and database for the policy server will be complex.

joeygrover on 11 Dec 2018

@mrapitis Yea that is not defined that way in the protocol spec. Which is more than documentation, it is the spec and if the code doesn't follow it or operates outside of it, that is a bit of a concern.

joeygrover on 11 Dec 2018

Actually service 10 and 11 can also behave in the same way, if the force protection ini keyword is not turned on for the service, the app can send data encrypted or unencrypted for that service and the service can be started multiple times with encryption on or off.

mrapitis on 11 Dec 2018

No Sample Encryption library Android
I would warn that there is currently no example library of how to build an encryption library for Android. I understand the author stated the "how" is out of scope, but I see that as a concern that should be addressed before this proposal is accepted or implemented.

I agree this is a very reasonable concern. Without Sample Encryption library, this feature cannot be tested at all. But I don't think it is a reason not accepting this proposal.

yang1070 on 11 Dec 2018

No Sample Encryption library Android
I would warn that there is currently no example library of how to build an encryption library for Android. I understand the author stated the "how" is out of scope, but I see that as a concern that should be addressed before this proposal is accepted or implemented.

I agree this is a very reasonable concern. Without Sample Encryption library, this feature cannot be tested at all. But I don't think it is a reason not accepting this proposal.

It should also be noted that the sample android security library is needed for OEM's making use of any encrypted service including service 10 and 11 -- it is not specific to service type 7 or this proposal.

mrapitis on 11 Dec 2018

@mrapitis You are correct. It is still a concern as it stands. However I believe a proposal like this that would affect all SDL apps vs only VPM the concern grows. I don't believe we need an example before the proposal is accepted, but I would recommend a plan of action on how and when it would be contributed.

joeygrover on 11 Dec 2018

👍1

@yang1070 The update to the policy server is complex for per app control of RPC per encryption requirement. While the policy table seems straightforward, enabling such control into a UX and database for the policy server will be complex.

The simplest way to me is to create a new group for each new app (certainly it will increase the db size and the amount of traffic, thus it is not a good solution), in this way for each app, all RPCs are listed and there is a check box to say the PRC needs protection or not. The UI shall be simple and clean.

On the other hand, we can relax the encryption requirement to all new apps to certain RPC groups, for example (1) remote control RPCs for security (2) vehicle data related RPCs for privacy (3) onKeyboardInput RPC for users input of passwords.

yang1070 on 11 Dec 2018

Is there a reason to do per RPC encryption? It is stated in your proposal that the web moving from HTTP to HTTPS is an example. Current standards are to encrypt everything on the web, even static pages that have no logins, etc. It seems that either: 1. requiring an app to use an encrypted service or 2. don't require the app to use an encrypted service would be much simpler than defining per-RPC requirements for individual apps.

Additionally, as encryption requirements get stricter in the changing web / vehicle / connected everything landscape, I feel an all or nothing approach (production should always be all) is a better system than creating unneeded complexity that also leaves some aspects unencrypted. Think of this as a bit of future proofing.

BrettyWhite on 11 Dec 2018

@BrettyWhite We have considered all or nothing solution, and we would like to see that all RPC messages are encrypted. The primary reasons we choose this are we want (1) the new apps or update versions of existing apps work with the old head units (that we cannot update and old sw does not require encryption) (2) the old apps (that does not have a security lib, thus cannot do encryption) works with the new head units

For example, in the case of an application with different versions (old versions that does not need protection, new version that have new functions, it uses new RPCs and needs protection), if we have just one flag to say this app need protection or not, old versions will not work with new head units.

yang1070 on 11 Dec 2018

It can also be an expensive operation to encrypt every last message. The cloud typically has the luxury of a higher performance server while a vehicle hu may be much more conservative.

mrapitis on 11 Dec 2018

@yang1070 The encryption library might need to be able to detect the head unit then and force encryption on modern units and allow plaintext on old ones. I imagine this is an issue as well even with the selective approach. It seems the OEM would have to maintain the list and enforce that for individual car models.

@mrapitis Aren't nav apps required to use an encrypted transport currently? I can't imagine templated apps creating anywhere near the traffic that something that streams video does.

BrettyWhite on 11 Dec 2018

@brettywhite that’s up to each individual OEM. SDL core can be configured to not require encryption at all for any service.

mrapitis on 11 Dec 2018

@yang1070 The encryption library might need to be able to detect the head unit then and force encryption on modern units and allow plaintext on old ones. I imagine this is an issue as well even with the selective approach. It seems the OEM would have to maintain the list and enforce that for individual car models.

@BrettyWhite What encryption library does is to obtain a certificate from OEM's server and start DTLS/TLS handshake with head units with the downloaded cert, it cannot detect the head unit.

OEM does not need to maintain the list for individual car models, it maintains the app list and the new RPCs that need encryption.

Let's say all remote control RPCs need encryption, an update of the existing apps add a new feature of climate remote control to the app, on old head unit, the update version of the app will only lose the new feature but keep other features working with the selective approach. But with all/nothing approach, other feature will be affected too.

yang1070 on 11 Dec 2018

@nickschwab @crokita Can you comment on the work that would be necessary to the policy server to add this level of functionality? It's not so much what the UI could look like, but how to actual code it into what we have today as well as being able to adjust the database to handle it. Each update to the policy server needs to be backwards compatible so creating scripts to migrate from one database scheme to the next is time consuming and can be error prone.

I believe if the HU receives a StartService with encryption bit set and no encryption is set for that service would it not just remain unencrypted? I think adding the RPC by RPC approach is dynamic, but the complexity might not be worth it. Why not allow OEMs to slowly roll out encryption requirements for the RPC service and warn app developers they need to update or they will lose features? Or Core could recognize older RPC/protocol versions and enforce the encryption based on a threshold.

joeygrover on 11 Dec 2018

I believe if the HU receives a StartService with encryption bit set and no encryption is set for that service would it not just remain unencrypted?

yes. I think so.

yang1070 on 11 Dec 2018

I think adding the RPC by RPC approach is dynamic, but the complexity might not be worth it. Why not allow OEMs to slowly roll out encryption requirements for the RPC service and warn app developers they need to update or they will lose features?

I agree this is an option. Basically, instead of each RPC having a Boolean flag, the whole app has a Boolean flag needProtection in app policy. And it is added as a optional parameter to OnPermissionsChange RPC. OEMs can choose to do nothing about the existing apps (no app policy change or add needProtection=false). For a new app, an OEM can choose to require either all RPCs of the app or none RPCs of the app to be encryption enabled. For example, for a new RC app, an OEM say needProtection=true for this new app. SDL will get the config from policy server, and send it to the app, then the proxy can start the process of enable encryption right after it receives OnPermissionsChange message. After that, all RPC messages shall be encrypted for this new app.

yang1070 on 11 Dec 2018

👍1

@yang1070 @joeygrover Defining which RPCs require encryption on a per-app basis would create a lot of unnecessary Policy Server overhead in regard to: OEM app administration (UI), database schema/storage, and policy table generation. In order to accommodate per-RPC encryption settings, a new "RPCs" tab would need to be built into the Policy Server, along with the back-end APIs and database schema to support it. It's a non-trivial amount of work that would complicate the UI/UX of the Policy Server configuration for every OEM, now and in the future.

From security and ease-of-setup standpoints, I agree with @BrettyWhite that encrypting all RPCs is a stronger argument than only encrypting select RPCs. While performance would vary by OEM hardware configuration, I firmly believe that securing all RPC data coming into and out of SDL is in the best interest of consumers, developers, and OEMs. It would be the responsibility of the OEM to ensure their hardware is capable of performing the encryption/decryption at an acceptable speed.

With this in mind, I suggest:

RPC Encryption is toggled on a global level. Either all RPCs are encrypted, or none are. This should be determined by a boolean setting in Core and included in the policy table snapshot module config, e.g. rpc_encryption_enabled.
New app_policies boolean attribute rpc_encryption_required tells Core whether or not the application is required to use RPC encryption. If both Core's rpc_encryption_enabled flag is true and the app's rpc_encryption_required flag is true (both flags are controlled by the OEM), then RPC Encryption is enforced.
For backward compatibility, RPC Encryption remains OFF for existing versions of applications in a Policy Server (even if Core has RPC Encryption enabled)
Policy Server start-up configuration setting controls whether or not the "RPC Encryption Required" toggle is defaulted to "ON" or "OFF" when a new application enters OEM review. OEM may override the setting during application review. Automatic app approvals would use the system default setting.

nickschwab on 12 Dec 2018

The Steering Committee voted to return this proposal for revision on 2018-12-11. It was concluded that the more details are needed on the complexity of the having an individual RPC vs. all RPC’s being encrypted as difficulty not only comes from the mobile libraries and core but how it is going to affect the policy server.
The author is to add more descriptive elements of the pro and cons between the two solutions. When descriptions for both the selective approach and an all or nothing approach are given, it will need to be clear that if the all or nothing RPC was chosen then lowering the complexity etc. and if we say we give the ability to do an individual RPCs; it would be possible to state in the proposal that the policy server does not implement that, but maybe the policy server only supports all or nothing but it still builds the policy table in a way that can still be recognized by core for the individual RPCs. The SDLC would have to understand that they are not going to get this functionality out of the box and that each individual OEM that adopts the policy server would have to implement this themselves.
Additionally, the proposal should state that along with this implementation a sample security library for Android would be supplied. A new proposal defining what changes would be required for both mobile libraries (example: the manager layers working through the permission manager for encryption information) and how it won’t increase the app developers burden of work beyond dropping in a security library.

jordynmackool on 12 Dec 2018

Have you benchmarked the performance against legacy hardware to determine the degradation of speed for encrypting all RPCs? If this hasn't been done, I propose that this be tabled until it has. If it has, can we see the results?

I am also worried about this section in particular:

Meaning that while SDL core and the policy table structure will allow different RPCs to require encryption per different app, the policy server would not make these fully available. Instead, the SDL Policy Server shall give OEMs the option to select which RPCs they need to be encrypted that will apply to ALL of their partner apps.

I think that while _not_ having an all or nothing approach is bad enough, forcing OEMs to not have granular control of what they encrypt on a per app basis via the policy server is a bad precedent to set.

For the platform as a whole I believe this system is over-complicated and will add bloat that is confusing to hardware partners and app partners alike. I highly encourage having a plan to transition to an all or nothing approach while not having to support this setup in the future if passed as is. As I stated before, and something that is in your example - moving from HTTP to HTTPS, it is bad practice to load a HTTPS page and have http links loading within it.

BrettyWhite on 15 Jan 2019

👍1

I would also like to note, CarPlay, Which current head units support, encrypt their entire stream:

AirPlay audio and CarPlay video streams utilize the MFi-SAP (Secure Association Protocol), which encrypts communication between the accessory and device using AES-128 in CTR mode

Source: https://www.apple.com/business/site/docs/iOS_Security_Guide.pdf

BrettyWhite on 15 Jan 2019

I think that while not having an all or nothing approach is bad enough, forcing OEMs to not have granular control of what they encrypt on a per app basis via the policy server is a bad precedent to set.

I'm not sure a precedent is being set as SDL already has the capability to allow the app developer to choose which RPC's to encrypt in a granular way (this is not new functionality and exists today). This proposal is providing functionality to allow OEM's to require specific RPC's to be encrypted (e.g. RC based RPC's).

mrapitis on 15 Jan 2019

SDL already has the capability to allow the app developer to choose which RPC's to encrypt in a granular way

That is the definition of a precedent right? I'm saying that this is making it even deeper. It is a bad practice and we should stop it from happening. In the end, it is up to us to not only protect the vehicles, but also the consumers who might not know better in terms of how their data is being handled.

BrettyWhite on 15 Jan 2019

@BrettyWhite I cannot agree your option below

I think that while not having an all or nothing approach is bad enough, forcing OEMs to not have granular control of what they encrypt on a per app basis via the policy server is a bad precedent to set.

The proposal is not forcing OEM to not have granular control. It only proposes that open source policy server will not provide granular control by default. The proposal allows granular control. OEMs can have their own implementation if they need granular control.
Encryption for RPCs is an emergent need. If the system cannot afford encrypt all traffics on existing hardware, it shall be able to encrypt selected RPCs. I don't think "not having an all or nothing approach is bad".
Unlike SDL, in CarPlay, secure communication transport is the base, the system is designed based on it. In SDL, encryption is an add on, not a base. Ideally, SDL shall be able to set up an encrypted channel before an app start register app interface. But it is not the case so far. The app need to register app interface, then start encryption.

yang1070 on 15 Jan 2019

@yang1070 have benchmark tests been run?

BrettyWhite on 15 Jan 2019

I agree with @BrettyWhite that performance benchmarks should be completed to evaluate the performance impact of encrypting all RPCs on legacy hardware (defined as model year 2018?) prior to ruling it out as an option. From security and ease-of-implementation perspectives for all involved parties, an all-or-nothing encryption approach would be best, as I outlined in this previous comment to support backward-compatibility.

nickschwab on 15 Jan 2019

@BrettyWhite @nickschwab It is easier to be said than done for a performance test. We don't have a test suits designed yet, not to mention to run it. Currently, I'm thinking of the response time (the time to start an RPC request and the time of a RPC response received, but it is per PRC message, not for all RPCs) and system CPU usage on average.

yang1070 on 15 Jan 2019

@yang1070 to their point, if you claim performance issues are why we can't do all or nothing then there should be evidence of that claim.

joeygrover on 15 Jan 2019

I understand tests can be time consuming.

If RPC encryption is needed urgently for RC applications, could we use the existing security infrastructure used by Nav apps for RC applications?

In terms of vehicle security, the future is encrypting everything and there is a lot of literature in the field of cyber security about this, including papers like this: State of the Art: Embedding Security in Vehicles

If possible, I think we should try and work together on a solution that provides all of the advantages, including the point you made earlier:

"Ideally, SDL shall be able to set up an encrypted channel before an app start register app interface"

In terms of SDL being a more and more integrated part of the vehicle platform (as it is becoming with RC modules), getting this part right is the future of the platform and that shouldn't be rushed or feel rushed.

As stated in the conclusion of the paper I linked:

IT security solutions have to be designed extremely carefully. A single “minor” flaw in the system design can render the entire solution insecure. This is quite different from engineering most other technical systems: a single non-optimum component usually does not invalidate the entire system.

I would invite us all to work on a long term solution for the platform that is secure, efficient, and friendly for all involved.

Edit: spelling

BrettyWhite on 15 Jan 2019

If RPC encryption is needed urgently for RC applications, could we use the existing security infrastructure used by Nav apps for RC applications?

actually, we are re-using the existing security infrastructure used by Nav apps. How do the Nav app work? The flow is that, the app registers app interface, the app start a new service (for video data or audio data), during the start a new service, the sdl core need to get the policy data (for example certificate ) of the app using un-encrypted systemRequest RPC and onSystemRequest RPC, and once the new service is started, all traffic on this new service is encrypted.
We do similar things here, set up a new secured RPC service, all RC requests are on this new RPC service. Then that is the same. Then next step, how to tell a request is a RC request? a static hard coded list (like Nav apps) or a dynamic list. We choose the dynamic list that is configurable by policy. Then next step, since current RPC 7 can support both encrypted and not encrypted RPCs, we remove the new secured RPC service and reuse the existing one. We don't change how app get authenticated and how to set up encryption. That is the same as NAV apps. That's exactly, the current proposal. So the major difference from Nav apps is the static RPC list and the dynamic RPC list.

yang1070 on 15 Jan 2019

The so called "ALL" or nothing approach does not exit. Even when the policy can say "all" RPCs need encryption, the RPCs like registerAppInterface/SystemRequest/OnSystemRequest are still not encrypted. Because they are required to exchange information before a secure channel is set up. So the All approach is only to say after certain point, the RPC messages are encrypted, not all RPCs are encrypted.

Performance is one factor that we submit this design. Another factor is that we only need certain RPCs with higher risk (RC related) to be encrypted. We don't have requirements for low risk RPCs. All is good, but it does not satisfy the current need. The proposal can achieve all or nothing and more than that , the partial. This is not that complex in the sdl core or proxy. It may be complicated in the policy server, but it can be implemented on a as needed basis. If OEM just need all or nothing, there is no additional effort for it.

yang1070 on 15 Jan 2019

Thank you for the explanation.

actually, we are re-using the existing security infrastructure used by Nav apps

It is difficult to imagine RPC bandwidth exceeding that of encrypted video, if the system uses the same infrastructure. This is why I believe a performance analysis is needed prior to accepting this proposal

There are examples where many RPCs could contain protected information. There is still "risk" in low risk.

Show RPCs can show protected information (think insurance app showing an account number on the screen, health apps displaying health information, etc).
Vehicle data RPCs could allow attackers information on drivers and their habits, including location.
Speak RPCs could speak protected information
RC data needs protection while modifying the states of safe modules in the car.
Future RPCs would be immediately protected
Anything that is plain text could be subject to a Man In The Middle (MITM) attack

Apps could display protected data through non-protected RPCs. Just as the companies must protect consumers with things like back up sensors that, at one time were not a requirement; planning ahead for the safety of the consumers, long term, should be considered highly important and as an investment in the future especially as cars become more digitized.

For example, it might be confusing to developers where one OEM might protect one RPC while another does not. The system as a whole should be as fluid as possible between OEMs.

Again, this is best achieved by encrypting all that can be. Thank you for pointing out those RPCs that would have to be omitted, everything else should not be.

BrettyWhite on 15 Jan 2019

👍1

Your list of examples just show the advantage of the current design. While it meets the urgent need of encryption RC realted RPCs. The OEM can expand that list when necessary with just back-end policy configuration changes and no SDL core or proxy changes. And eventually, when it is ready, almost all RPC can be encrypted.

yang1070 on 15 Jan 2019

I think the point is still being missed. Disparity amongst OEMs in this area can be very bad for the end user. I would also like to avoid one entity making the decisions of what information (that isn't likely being generated by them - in terms of apps) be protected or not.

BrettyWhite on 15 Jan 2019

@yang1070 However, the currently proposed design would add complexity to the Core and client side libraries that would have to be maintained indefinitely. So the point stands that encrypting everything solves all those problems without an increase in complexity (at least at the rate of the proposed) where the proposal introduces complexity and technical debt that would have to be carried until the feature could be removed and the projects working in the all or nothing scenario.

joeygrover on 15 Jan 2019

@yang1070 If an app has been built and released according to select RPC encryption requirements by an OEM at that moment in time, then the OEM later updates their policy server to require additional RPCs to be encrypted, what would happen to the already-published application? Would it break? Surely that wouldn't be an acceptable answer, so your proposed solution would require significant RPC-level versioning and require that apps could specify what RPC security enforcement version to support. That's a lot of complexity and technical debt for something that could be resolved in an all-or-nothing fashion at (essentially) the transport level.

Your list of examples just show the advantage of the current design. While it meets the urgent need of encryption RC realted RPCs. The OEM can expand that list when necessary with just back-end policy configuration changes and no SDL core or proxy changes. And eventually, when it is ready, almost all RPC can be encrypted.

nickschwab on 15 Jan 2019

@nickschwab The list of RPCs that must be encrypted would come through an OnPermissionsChange so the idea is that OEMs can change these RPCs on the fly, the app woudl receive the list of RPCs to encrypt and one of two things would happen:

App is already setup to do encryption with OEM unit. The library would take the new requirements and encrypt those as well as the system is dynamic to match the module's status it connects to.
App is not setup to do encryption. The app would not be able to send those RPCs. This is where the granular control would be nice for OEMs so they could give app developers time to update and become ready.

joeygrover on 15 Jan 2019

It is difficult to imagine RPC bandwidth exceeding that of encrypted video, if the system uses the same infrastructure. This is why I believe a performance analysis is needed prior to accepting this proposal

currently, video is only work on USB transports, and with 5.0 it will work on secondary WiFi transport, which are all high band width. But RPCs shall also work on BT transports. That is the major difference.
It is not either encrypted video or encrypted RPC. It is both encrypted video and encrypted RPC running at the same time, if encryption is enabled.
Even without a performance test, I can see the issue. Now in our systems, when I launch a mobile navigation app, it takes a much longer time than to launch a non-nav regular app. When I launch a regular app, usually I see the app screen get shown immediately and music played immediately. But when I launch a nav app, most of the time, I see a loading screen (with uncertain time, sometimes it dismissed quickly, but most of the time it is shown for seconds and longer, and there are a lot of issues around that). If we do the "all" approach, then I will see loading screen for all apps, not just a very few Nav apps. That's not acceptable.
On the existing hardware, we have experienced the low performance for multiple apps get registered on BT device. Enable encryption for all RPCs and all apps can only make it worse due to the additional message exchange to set up encryption.

yang1070 on 15 Jan 2019

Encryption/decryption is unrelated to transport. Those operations are pre and post transport so I don't believe this point is valid.
Encryption is at the service level not the session so any and all mutations of encrypted and unencrypted services can be made simultaneously.
This is not evidence nor should be taken as such. Honestly this point makes the argument of accepting this proposal weaker. Until you can identify the exact cause of the performance issue no solution should be created. This is a point I brought up earlier. I'm not all against this proposal but I am against accepting it merely on the "idea" that it could solve an issue. If there is not concrete evidence that encrypting some vs all RPCs will improve performance then that shouldn't be taken into consideration. So what exactly in the encryption setup process is taking so long?
This is an unrelated issue. There could be any number of ways to improve performance of the SDK sending 2-3 extra messages is not a huge burden on the system.

joeygrover on 15 Jan 2019

@joeygrover I see, but that still seems like technical debt and unnecessary complication within the library. As @BrettyWhite mentioned, I think the most important issue here is that there should be consistency across OEMs regarding what is encrypted (and what better way to do that than to encrypt everything?), otherwise app developers and consumers will be left vulnerable to having different portions of their apps insecure across different OEMs. As an app developer or consumer, I shouldn't have to worry about whether or not certain RPCs/parts of an app are encrypted or not depending on which vehicle I'm in... That would be like me walking into car dealerships and needing to ask if their vehicles have steering wheel airbags installed so I know whether or not my safety is at risk.

@nickschwab The list of RPCs that must be encrypted would come through an OnPermissionsChange so the idea is that OEMs can change these RPCs on the fly, the app woudl receive the list of RPCs to encrypt and one of two things would happen:

App is already setup to do encryption with OEM unit. The library would take the new requirements and encrypt those as well as the system is dynamic to match the module's status it connects to.

App is not setup to do encryption. The app would not be able to send those RPCs. This is where the granular control would be nice for OEMs so they could give app developers time to update and become ready.

nickschwab on 15 Jan 2019

@nickschwab the list supplied by the module through the OnPermissionsChange is only a list of required RPCs from the module. An app developer always has the option to encrypt any and all RPCs for themselves. The case they would run into is if a head unit supports encryption or not and at this point encryption support is not a requirement from an SDL standpoint. Therefore those apps would simply not connect to the head units it can't trust giving full control to the app developer.

joeygrover on 15 Jan 2019

I think Nick's point in that last post is that while technical debt is bad and this definitely adds it - That our greater concern should be unity in the platform and concern for our partner apps and end users (the vehicle owners). They deserve current best practices and we owe it to them to provide it.

BrettyWhite on 15 Jan 2019

@BrettyWhite Correct.

I think Nick's point in that last post is that while technical debt is bad and this definitely adds it - That our greater concern should be unity in the platform and concern for our partner apps and end users (the vehicle owners). They deserve current best practices and we owe it to them to provide it.

nickschwab on 15 Jan 2019

I think that goes to a larger question of should all data sent through SDL be encrypted or not, not just relating to RPCs. Some transports already provide encryption around everything sent, bluetooth, and MFi chip (USB and bluetooth) for example. So some of this would be encrypted traffic that goes through an encrypted transport as well. I would have to double check on AOA, but obviously TCP is not encrypted by default.

joeygrover on 15 Jan 2019

@joeygrover

Encryption/decryption is unrelated to transport. Those operations are pre and post transport so I don't believe this point is valid.

Encrypted data message is transmitted over a transport. If Encryption add more data to the the message, or more messages to the traffic, then it get related. It may not be a problem on high band width transport, but it will be a problem for a low band with transport.

Loading time is a performance issue.
The hypothesis of multiple apps slow registering issue is the amount of messages and data burst in a short period of time. additional messages sending at the same period can make it worse.

yang1070 on 15 Jan 2019

The Steering Committee voted to defer this proposal on 2019-01-15. A SDLC workshop will be scheduled to further discuss encrypting all RPCs or encrypting individual RPCs only.

jordynmackool on 16 Jan 2019

The Steering Committee took part in a workshop regarding this proposal on 2019-01-24. Meeting minutes from the workshop are attached with action items in red.

2019-01-24- SDL -0207- RPC Message Protection Workshop Minutes.pdf
Appendix B.pdf
Appendix A.pdf

jordynmackool on 25 Jan 2019

Overview

Three modifications to the Policy Table were evaluated with the goal of allowing an OEM to designate which RPCs are required to be encrypted/protected in order to be used by an app developer. This has been identified as a short-term solution, while the long-term solution is to support and require the encryption of all SDL communication at the transport level.

Option 1: New `rpcs` struct within the Policy Table

This new struct would reside in the root level of a Policy Table and would define all RPCs as well as whether or not they require encryption. While providing a very clear representation of which RPCs are encrypted, this new struct would increase the size of the Policy Table considerably and introduce a new layer of Policy Table interpretation by SDL Core.

For example:

...
"rpcs": {
    "GetVehicleData": {
      "encryption_required": true
    },
    "OnVehicleData": {
      "encryption_required": true
    },
    "SubscribeVehicleData": {
      "encryption_required": true
    },
    "UnsubscribeVehicleData": {
      "encryption_required": true
    },
    "Alert": {
      "encryption_required": false
    },
    "AddCommand": {
      "encryption_required": false
    },
    "AddSubMenu": {
      "encryption_required": false
    },
    "CreateInteractionChoiceSet": {
      "encryption_required": false
    },
    "DeleteCommand": {
      "encryption_required": false
    },
    "DeleteFile": {
      "encryption_required": false
    },
    "DeleteInteractionChoiceSet": {
      "encryption_required": false
    },
    ...
},
...

Option 2: New attribute within Functional Groups

A new attribute (encryption_required: boolean`) to be added within the existing functional group struct to designate the OEM encryption enforcement for all RPCs within the group. If an app has access to multiple functional groups containing the same RPC and at least one of the groups requires encryption, then the RPC shall require encryption.

For example:

...
"functional_groupings": {
  "Location-1": {
>>>>"encryption_required": true,<<<<
    "user_consent_prompt": "Location",
    "rpcs": {
      "GetVehicleData": {
        "hmi_levels": [
          "BACKGROUND",
          "FULL",
          "LIMITED"
        ],
        "parameters": [
          "gps",
          "speed"
        ]
      },
      "OnVehicleData": {
        "hmi_levels": [
          "BACKGROUND",
          "FULL",
          "LIMITED"
        ],
        "parameters": [
          "gps",
          "speed"
        ]
      },
      "SubscribeVehicleData": {
        "hmi_levels": [
          "BACKGROUND",
          "FULL",
          "LIMITED"
        ],
        "parameters": [
          "gps",
          "speed"
        ]
      },
      "UnsubscribeVehicleData": {
        "hmi_levels": [
          "BACKGROUND",
          "FULL",
          "LIMITED"
        ],
        "parameters": [
          "gps",
          "speed"
        ]
      }
    }
  },
  "Notifications": {
>>>>"encryption_required": false,<<<<
    "user_consent_prompt": "Notifications",
    "rpcs": {
      "Alert": {
        "hmi_levels": [
          "BACKGROUND",
          "FULL",
          "LIMITED"
        ]
      }
    }
  },
  ...
},
...

Option 3: New attribute within Functional Group RPCs

Similar to Option 2, but the new attribute (encryption_required: boolean) to be added and configurable within each rpcs object of existing functional groups to designate the OEM encryption enforcement for the specific RPC.

For example:

...
"functional_groupings": {
  "Location-1": {
    "user_consent_prompt": "Location",
    "rpcs": {
      "GetVehicleData": {
>>>>>>>>"encryption_required": true,<<<<<<<<
        "hmi_levels": [
          "BACKGROUND",
          "FULL",
          "LIMITED"
        ],
        "parameters": [
          "gps",
          "speed"
        ]
      },
      "OnVehicleData": {
>>>>>>>>"encryption_required": true,<<<<<<<<
        "hmi_levels": [
          "BACKGROUND",
          "FULL",
          "LIMITED"
        ],
        "parameters": [
          "gps",
          "speed"
        ]
      },
      "SubscribeVehicleData": {
>>>>>>>>"encryption_required": true,<<<<<<<<
        "hmi_levels": [
          "BACKGROUND",
          "FULL",
          "LIMITED"
        ],
        "parameters": [
          "gps",
          "speed"
        ]
      },
      "UnsubscribeVehicleData": {
>>>>>>>>"encryption_required": true,<<<<<<<<
        "hmi_levels": [
          "BACKGROUND",
          "FULL",
          "LIMITED"
        ],
        "parameters": [
          "gps",
          "speed"
        ]
      }
    }
  },
  "Notifications": {
    "user_consent_prompt": "Notifications",
    "rpcs": {
      "Alert": {
>>>>>>>>"encryption_required": false,<<<<<<<<
        "hmi_levels": [
          "BACKGROUND",
          "FULL",
          "LIMITED"
        ]
      }
    }
  },
  ...
},
...

Conclusion

I recommend Option 2 (new attribute within Functional Groups) since it achieves the SDLC's short-term goals while:

Minimizing the size increase of the policy table
Minimizing complexity of Policy Table generation
Minimizing complexity of the Policy Server interface

nickschwab on 25 Jan 2019

@lauratonwe, Please see Nick's comment above.

jordynmackool on 28 Jan 2019

Would be valuable to get @JackLivio's opinion of the proposed Policy Table addition from the perspective of Core as well.

nickschwab on 28 Jan 2019

@nickschwab I agree that option 2 is the best approach. The main use case wants to force encryption for a specific group of RPCs (ie Remote Control).

In option 3, adding the flag to each RPC entry would bloat the policy table.

JackLivio on 28 Jan 2019

Revisions have been made by the author based on the outcome of the workshop that was held on 2019-01-24. The new review of "SDL 0207 - RPC message protection" begins now and runs through February 5, 2019.

jordynmackool on 30 Jan 2019

need_protection

The author didn't use the requested naming from the project maintainer. It should be encryption_required. At the very least protection_required.

SDL server updates:

The SDL server may support the new parameter in the policy table.

This is a bit lacking for a description of changes required.

App specific encryption requirement

I would also like to see a flag added in the policy table per app that describes if they are required to comply with the encryption or not. This might be redundant due the ability to make near duplicate functional groups with the only change being the required encryption flag set to true, however I believe the flag will be useful in the future as we discussed the desire and plan to move to full transport encryption. So if the app entry had the flag set to true, Core would honor the requirements of the subsequent functional groups, but if the flag was absent or set to false, Core would ignore the requirement for that app.

Race condition

I believe we have missed the possible race condition between an app using an RPC that requires an encrypted service vs when the app receives the OnPermissionChange update that conveys that information. While it can be said, the app must simply try again, the logic to handle this in the managers might be a bit of work to handle it correctly.

joeygrover on 5 Feb 2019

Sure, we can change the name from need_protection to encryption_required in function group level. And add a app level flag

    "default": {
+     "encryption_required": false,
      "keep_context": false,
      "steal_focus": false,
      "priority": "NONE",
      "default_hmi": "NONE",
      "groups": [
        "Base-4"
      ]
    }

Regarding SDL server update, I'm not aware how sdl server is designed and what the implementation is, as long as it sends the PTU with added parameters, it is good to me.

yang1070 on 5 Feb 2019

App specific encryption requirement

I would also like to see a flag added in the policy table per app that describes if they are required to comply with the encryption or not. This might be redundant due the ability to make near duplicate functional groups with the only change being the required encryption flag set to true, however I believe the flag will be useful in the future as we discussed the desire and plan to move to full transport encryption. So if the app entry had the flag set to true, Core would honor the requirements of the subsequent functional groups, but if the flag was absent or set to false, Core would ignore the requirement for that app.

@joeygrover Good point. This is required to ensure backward compatibility with applications already in production so they can continue to work without encryption. I suggest this new flag to also be named encryption_required and to default to false. This additional flag in the app_policies portion of the Policy Table should be set by the Policy Server upon the OEM's application approval, based upon a new startup configuration variable in the Policy Server named app_encryption_required to allow for a point-in-time change by the OEM. This boolean could be manually overridden by the OEM via a toggle in the Policy Server app review UI should they need to make any one-off exceptions.

Regarding SDL server update, I'm not aware how sdl server is designed and what the implementation is, as long as it sends the PTU with added parameters, it is good to me.

@yang1070 SDL Server updates include:

Database and API modifications to support the new encryption_required attribute of Functional Groups.
UI addition of a checkbox or toggle-switch to enable/disable the state of encryption_required for a Functional Group.
Database and API modifications to support the new encryption_required app_policy attribute.
New app_encryption_required server environment variable to indicate whether auto-approved applications should automatically have their encryption_required app_policy value set to true or false (default false)
UI addition of a checkbox or toggle-switch to enable/disable an individual application version's encryption_required app_policy value.
API modifications to build Policy Tables with the new encryption_required attributes in Functional Groups and App Policy structs.

nickschwab on 5 Feb 2019

The Steering Committee voted to accept this proposal with revisions. The revisions will include adding a flag in the policy table per app that describes if they are required to comply with the encryption or not as noted in this comment.
There was additional discussion in regards to whether or not this encryption will be used in core from the policy table, essentially authentication and validation or if this flag needs to be passed from core into the proxies. It was determined that it is almost inferred by the proxies if they get an on-permission change with the new RPCs that are delegating they need to be encrypted and the app itself would need encryption, so core should send the on-permission changes to an app in regards to the RPC encryptions unless that app requires an encryption.

jordynmackool on 6 Feb 2019

Requested Revisions have been made and issues have been entered:
core
rpc_spec
ios
android
policy server

jordynmackool on 19 Feb 2019

Sdl_evolution: SDL 0207 - RPC message protection

All 64 comments

Question 1: RPC encryption activation timing

Question 2: Alternative Encrypted RPC Service

Question 3: Apps that don't use the protected RPCs

SDL server updates:

Alternative New Service

No Sample Encryption library Android

Overview

Option 1: New `rpcs` struct within the Policy Table

Option 2: New attribute within Functional Groups

Option 3: New attribute within Functional Group RPCs

Conclusion

SDL server updates:

App specific encryption requirement

Race condition

App specific encryption requirement

Related issues

Sdl_evolution: SDL 0207 - RPC message protection

All 64 comments

Question 1: RPC encryption activation timing

Question 2: Alternative Encrypted RPC Service

Question 3: Apps that don't use the protected RPCs

SDL server updates:

Alternative New Service

No Sample Encryption library Android

Overview

Option 1: New rpcs struct within the Policy Table

Option 2: New attribute within Functional Groups

Option 3: New attribute within Functional Group RPCs

Conclusion

SDL server updates:

App specific encryption requirement

Race condition

App specific encryption requirement

Related issues

Option 1: New `rpcs` struct within the Policy Table