S-63 Confusion

[bcn]

Originally Posted by bukko

An alternative would be to request a new M_KEY.
It would be easier if the userpermit contained details of the client software release, but unfortunately it doesn't and probably won't until S.63 2.0 is released, which is some time away.

Seems that there will not be anything like an S-63 V.2.0
S-100 is already in place (since 2010) and on the S-101 Standard - that's the part concerning ECDIS - the IHO is working. So it looks to me that they will not waste any capacity on the S-63 anymore.

S-57 and S-63 will stay as delivery formats for a lot of time however.
Means that a S-63 plug-in will be valid for the next 10 (?) years at least.
As an analogy (although it is not the same) think about the co-existence of NMEA0183 and NMEA2000

Originally Posted by bukko

On another point, I'd be interested to see how you get on with your opensource solution. I always thought it wasn't possible as you would need to black-box a lot of it.

No, software solutions, although not open-sourced, do exist: PolarView, CoastalExplorer, MaxSea, SeaFarer ChartViewer as examples for the recreational, not type-approved sector.
That's why we are curious to hear about from users of this programs about their experience with S-63 charts.

A S-63 plug-in for OpenCPN will have to be "closed source" to some extend. This has been explained Dave in some previous posts.

And in this context from an IHO paper (IHO S-101 The Next Generation ENC Product Specification, 2012):

Another important element in the development of the S-101 product specification is the requirement for test beds during the development lifecycle and beyond. TSMAD has begun the process of identifying items needed for the test beds. The main items are as follows:
- S-57 to S-101 open-source convertor
- S-101 open source data editor
- S-101 open source data viewer
- S-100/101 ECDIS reference Test Bed
In recognizing the need for test beds and to help promote the development of the S-101 Product Specification, the National Oceanic and Atmospheric Administration (NOAA) contracted ESRI to develop an S-57 to S-101 open source converter.

[bukko]

Originally Posted by bcn

Seems that there will not be anything like an S-63 V.2.0
S-100 is already in place (since 2010) and on the S-101 Standard - that's the part concerning ECDIS - the IHO is working. So it looks to me that they will not waste any capacity on the S-63 anymore.

Originally Posted by bcn

And in this context from an IHO paper (IHO S-101 The Next Generation ENC Product Specification, 2012):

As far as I'm aware S.101 is just the product specification, and the security scheme will be S.63 2.0.
But, I haven't been as involved with DPSWG recently and activity within the S.63 2.0 development group seems to have died off somewhat so maybe that isn't the case any more.
I'll try to find out.

[redcane]

Originally Posted by bukko

An alternative would be to request a new M_KEY.

Now that you say that, it seems so simple. If a web service is used to issue Machine IDs (M_ID), then the same web service can be used to notify of required updates. The updated software could then have a new M_KEY and require the M_ID be reissued.

Originally Posted by bukko

However, if a user is savvy enough to copy unencrypted data from temporary files or even debugging the ECDIS code, they're probably also capable of brute-forcing the protected charts. That way they get access to all charts, not just ones they have permits for.

On another point, I'd be interested to see how you get on with your opensource solution. I always thought it wasn't possible as you would need to black-box a lot of it.

Whether or not it is possible appears to depend on how strict the requirements are from the IHO/IHB. At this stage I see no reason the source code can't be open source, but we may need to issue compiled binaries with the M_ID embedded in the binary. Obviously someone who can debug the code will still be able to find this, but it appears to have been an acceptable "barrier to entry" for commercially available software. Ideally there would actually only be a very small module that handled the keys that would need to be compiled by the person responsible to the IHO for control of the keys. It would need some way to ensure that the code it was interfacing with wasn't going to leak the chart data though, so I think it would need to include the entire processing path up to the OpenCPN interface.

[bcn]

Originally Posted by redcane

It would need some way to ensure that the code it was interfacing with wasn't going to leak the chart data though, so I think it would need to include the entire processing path up to the OpenCPN interface.

It seems to me that bdcat in the post #28 of this thread lined-out how this be can be achieved.

I will try to put a paper together which methods/functions are required for the closed source part, the binaries, that has to be handled apart.

From my conversations I do not expect that there will be a scrutineering of the solution. It is a self-certifying process, where you risk to been thrown out if you don't comply with the terms of the agreement.
So simply not messing around with the solutions.

Question how to revoke a singular user permit or to force updates due to necessary amendments of the plug-in we will have to take our time to discuss. Personally I'm not a friend of software "calling home" without my knowledge.

[redcane]

Originally Posted by bcn

It seems to me that bdcat in the post #28 of this thread lined-out how this be can be achieved.

That outline is the OpenCPN plugin interface. I was hoping it would be possible to open source more of the plugin between that interface and the decryption, but I can not see any method to prevent someone compiling the open part of the plugin that prevents them from modifying the source to leak data. This means that the whole plugin would need to be supplied as a binary blob, rather than a smaller "sub-module". This doesn't mean it can't be open source, but it prevents people from compiling their own improvements and testing them with authentic charts. Since OpenCPN only gets access to the rendered output we can consider a risk of information leakage to stop there (although someone could work through many renderings supplied by the plugin to extract some information).

Originally Posted by bcn

Question how to revoke a singular user permit or to force updates due to necessary amendments of the plug-in we will have to take our time to discuss. Personally I'm not a friend of software "calling home" without my knowledge.

I wouldn't suggest a phone home function if we can avoid it. If we are updating the M_KEY then users would be unable to purchase further charts without updating, and this could replace any need for a phone home function.

[bdbcat]

In implementing the "open" part of the PlugIn, we will need to decide where to put the firewall, so to speak.

One logical place is as follows:
The OpenCPN S57 model treats the chart cell as a "Feature Dispenser", like a soda vending machine. Push the button, and you get a feature record, with all parameters available for downstream rendering. Keep pushing the button until there are no more features to render. You are then done rendering.

So, we could "black box" the upstream part of this data flow, and open source the downstream part. All S63 know-how is embedded within the black box blob, which could be delivered to the end user as part of the "User Permit" process.

This has the advantage of decoupling the cell encryption/validation/management from actual rendering, which is good.

However, a motivated programmer could certainly intercept the Feature "stream" by modifying the "open" part of the PlugIn. It would be possible to leak the unencrypted cell data by any of several methods, even so far as generating an standard (unencrypted) OpenCPN SENC file. Or even a valid s57 (x.000) cell file, equivalent to (but not identical to) the original cell.

We could make it harder to steal the data by moving the firewall further downstream, at the cost of program complexity and performance.

Ultimately, we black-box the entire PlugIn. Not pretty, but certainly do-able.

But we cannot prevent theft of data. Not possible. For example, we all by now know how to georeference any arbitrary ECS screen shot and turn it into a usable BSB (.kap) chart.


So, our question must be: "How high should the firewall be? What level of pain will sufficiently deter theft of the protected data? What will satisfy the data owners?"

This is not an easy question.
I invite discussion.

Dave

[bcn]

Dave,

what about to watermark the plug-in or to check from the closed binary the MD5 hash of the open part, so that we are sure that it is the "official" one?

Would imply that every time the open part is modified the closed binary plug-in would have to be updated as well.

Hubert

[redcane]

Or only some open source compilations would be usable. It still prevents users from making improvements and then using them with official charts.

I suppose it will still be possible to create test charts encrypted with a known key and use that to develop improvements.

[bcn]

End of confusion -

We have green light from the IHO for developing a S-63 plug-in for OPENCPN

[bukko]

That's obviously good, but because it's based on an opensource viewer you will need to convince the data servers that it is secure.
If not, they won't be supplying users with permits.

[bcn]

Well, the user permit we will supply under the OEM agreement with the IHO - if the providers will sell charts (S-63 encrypted) is up to them of course.

Although my understanding is when you approach a VAR (Value Added Reseller or Distributor) with your valid user permit he should serve you. That is why IHO entitles them to distribute.

And with UKHO (or Admiralty) we have convinced already one of the important players.

When we have more infos or progress we will report in the new S-63 plug-in thread. The first hurdle is taken though.

[bukko]

Well, there are currently some OEMs which have their S.63 signatures etc from the IHO but that at least some of the data servers won't support, mainly because of non-secure SENCs.

As for the UKHO, I'm guessing they approved in principal as the code doesn't exist yet.

You would be better off approaching IC-ENC though, then you would have the confidence of all their members, not just UKHO.

[bcn]

Your insights are very appreciated, thanks!

To contact the various providers is on our to-do-list.

From the IC-ENC web site my impression was that they are mainly focussed on their VARs and becomming a VAR is most probably not our aim.
So you recommend to give them a try as well? Can you perhaps provide me with some contact?

Hubert

[bukko]

PM sent re the contact question.

IC-ENC are one of many (well, not that many!) RENCs which are concerned with supporting VARs and the data providers. A somewhat more detailed description is here.

I think they are definitely worth a try. I have a feeling that they could give your product somewhat greater credibility.
At the end of the day, you really want data servers to be confident enough to permits for it.

[rgleason]

From document above the IC-ENC VARs are:
ChartCo
ChartWorld
Datema
Jeppesen Marine
MARIS
NAVTOR
Norwegian Hydrographic Service
United Kingdom Hydrographic Office