S-63 Confusion

[wolfaroo]

Hola...

I hope you are enjoying the summer (N).

Forgive me if this has been covered in detail before but after a few searches I could only find a couple of brief comments; why isn't it possible to develop a plug-in to allow the use of S-63 charts on OpenCPN? Most ECS's now accept all S-63 charts regardless of who produces them.

Clearly there are concerns regarding the illegal distribution of protected charts and, to that end, no doubt the developers would have to be very careful not to assist that process by publishing the encryption/decryption algorithms etc. Having said that, I don't understand why it couldn't be resolved through a chart permit management add-on or plug-in, allowing permit/license management, similar to PolarView NS for example.

I also realise I could be VERY far off the mark as my understanding is very limited in this area. It just seems, to me at least, to be a great shame that OpenCPN can't fully compete as a true global ECS due to the [relatively] small stumbling block of S-63 charts.

I would be grateful if anyone could help my confused mind (in this area at least!).

Happy sailing...

Neal

[bdbcat]

Neal....
Thanks for the note.

This is a case where theory and practice may have a hard time meeting.

The IHO carefully protects the technical details of S63. To get the specification necessary to develop an interface to S63, it is required that a company sign a fairly onerous licensing agreement with IHO to become what they call an "OEM".

There are ongoing security audit requirements, and strict reporting responsibilities on the part of the OEM. There are also non-disclosure clauses.

Nothing in the above precludes open source implementation, per se. It would be up to the implementor to follow the rules. This means such things as ensuring that plain-text (ie. decrypted) ENC cannot under any circumstances be written to disk. Security keys are never available in plain text, etc, etc.

It may not actually be possible to satisfy these requirements in a fully open source environment, but probably could be done in a firewalled two part PlugIn.

So, there could be a commercial PlugIn developed for OpenCPN which would allow S63 ENC access. But my opinion is that it would have to be undertaken by a corporate entity willing to accept the responsibilities in exchange for any revenue generated by selling the PlugIn.

So, any company takers? I'd love to see it.

Sorry that the answer is so mushy, but that is the way of proprietary content management, I'm afraid.

Dave

Dave

[wolfaroo]

Hi Dave,

Thanks for the detailed reply - actually I didn't find it too mushy!

Here's hoping someone does in fact take it on...

Cheers,
Neal

[soderbet]

Originally Posted by bdbcat

Neal....
Thanks for the note.

This is a case where theory and practice may have a hard time meeting.

The IHO carefully protects the technical details of S63. To get the specification necessary to develop an interface to S63, it is required that a company sign a fairly onerous licensing agreement with IHO to become what they call an "OEM".

There are ongoing security audit requirements, and strict reporting responsibilities on the part of the OEM. There are also non-disclosure clauses.

Nothing in the above precludes open source implementation, per se. It would be up to the implementor to follow the rules. This means such things as ensuring that plain-text (ie. decrypted) ENC cannot under any circumstances be written to disk. Security keys are never available in plain text, etc, etc.

It may not actually be possible to satisfy these requirements in a fully open source environment, but probably could be done in a firewalled two part PlugIn.

So, there could be a commercial PlugIn developed for OpenCPN which would allow S63 ENC access. But my opinion is that it would have to be undertaken by a corporate entity willing to accept the responsibilities in exchange for any revenue generated by selling the PlugIn.

So, any company takers? I'd love to see it.

Sorry that the answer is so mushy, but that is the way of proprietary content management, I'm afraid.

Dave

Dave

Hello Dave

My company are intrested to provide a s-63 module. But I can't figure out how to solve the license issue. Can you please contact me directly for any further discussions.

/ Thomas

[GordMay]

FWIW:
S-63
IHO Data Protection Scheme (Ed. 1.1, March 2008)
is available for download here
➥ Downloads for IHO Member States and Subscribers

Specifically:
➥ http://www.iho-ohi.net/iho_pubs/stan....1_EN_2008.pdf

[oem]

Originally Posted by soderbet

Hello Dave

My company are intrested to provide a s-63 module. But I can't figure out how to solve the license issue. Can you please contact me directly for any further discussions.

/ Thomas

Polar Navy - Marine Navigation Software made an S-63 module several years ago. I tried it myself, so I'm sure it works.

As far as I know the username 'brak', who from time to time makes entries in this forum, represents Polarnavy, and he does have deep technical knowledge on the subject.

So it might be an idea to contact him, through this forum, if the documentation on the IHO-site is not sufficient. The IHO-site does contain test-specs and a lot of supplementary documentation on folder structure, how to communicate changes etc.

[redcane]

I've had a quick read of the publicly available spec (http://iho.int/iho_pubs/standard/S-6...1_EN_Apr12.pdf), and it all looks pretty straightforward. Initially I thought it would be possible to make a tool that just decrypts S63 files to S57. The only gotcha is that the files are encrypted with a key unique to the device. To do this, the chart supplier (data server) needs a manufacturer key on file for the device manufacturer, and this key is used to decrypt a device specific encryption key. The chart supplier decrypts the device encryption key using the manufacturer key, so that they can then supply charts locked to that device because only that device has the decryption key to match.

It looks like the chart suppliers are given the list of manufacturer keys from the "Scheme Administrator" (the IHB or International Hydrographic Bureau). So to be able to get charts you need to request a manufacturer key from the IHB. This is the point where we hit legal/contractual (not technical) difficulties. To get the key you need to sign an agreement, no doubt wih some onerous penalties for misuse. Assuming you got a key, and gave it away freely for anyone to use, they would be able to revoke it and you would not be able to purchase charts under it.

Personally I think this system of forcing people to buy charts per device is abhorrent, if you want to update or change your hardware you have to buy the charts again. I guess there is still the possibility of compromising a manufacturer key and/or hardware id, then you can decrypt all the charts you want.

[bdbcat]

Redcane....

Thanks for the analysis.
I would love to see S63 support in OpenCPN. I see no unsolvable technical constraints.

But here is the rub: I judge it unwise for me personally to execute an agreement with the "Scheme Administrator" to obtain access to the algorithms and key management.

It is very important as an OpenSource developer NOT to execute non-disclosure documents. This is not for any vague political reason. Its purely practical. Who can trace where code comes from these days? But it is critical that there be no question that the base OCPN code is either original, or derivative from some other OpenSource code base.

There is a non-trivial business opportunity here, clearly. One could build a business to license and resell S63 chart cells to OpenCPN users. Fully virtualized, no bricks, no mortar. I would fully support any such project. Heck, if I were not DevLead on OCPN, I might try it myself.

So, any takers?

Dave

[oem]

Originally Posted by bdbcat

Redcane....
There is a non-trivial business opportunity here, clearly. One could build a business to license and resell S63 chart cells to OpenCPN users. Fully virtualized, no bricks, no mortar. I would fully support any such project. Heck, if I were not DevLead on OCPN, I might try it myself.

So, any takers?

Dave

S63 charts are already sold for instance by Chartworld Infos - www.chartworld.de. Still too expensive, IMHO, to compete with other charts. There is a business opportunity.

The main advantage and idea of S63/S57 is that you buy a an obligation to receive chart updates for 3, 6 or 12 months. Possibly more. So you always sail with up to date charts. Which is a good safety precaution, and in principle an obligation for every sailor to do always and check updates before each trip.

With an S63-plugin OCPN would really grow to a full scale navigation package.

In the danish sea area alle charts are now moved from an old outdated propritary format to the S57-format. At present it's under pilot-test on an Ipad and only through software sold by a licensed company.

I believe that other countries here in Europe will follow, so that leisure sailors all over will have to comply with rules similar to those for professional sailing. Including charts, but requirements of course adjusted to leisure sailing. See IEC 62376 CD v6.0

That chart format, - I'm sure, will be S63. I hope somebody takes the next step.

I can help testing it... :-)

[redcane]

Originally Posted by bdbcat

But here is the rub: I judge it unwise for me personally to execute an agreement with the "Scheme Administrator" to obtain access to the algorithms and key management.

It is very important as an OpenSource developer NOT to execute non-disclosure documents. This is not for any vague political reason. Its purely practical. Who can trace where code comes from these days? But it is critical that there be no question that the base OCPN code is either original, or derivative from some other OpenSource code base.

I can see the logic in that. But I think the situation here isn't quite the same - the specification is available without an NDA. To get a key you need to sign an agreement, but I doubt that agreement requires closed source code (or gives access to code that might be "pirated" into an open source project).

Initially I was just so disappointed with the DRM situation that I was more looking for a way around it (a la deCSS). I can understand a need to ensure the right charts are used and not tampered with, but for that you can use an SHA checksum, and you don't need encryption. I'm sure the large commercial shippers who have legal requirements are also not going to be pirating charts.

A more pragmatic approach of working within the system is no doubt a better idea. I think I could take this on under a non-profit model, but I can't guarantee results or time frames. I don't think I'm prepared to take this on as a business simply as I don't have the time to invest in it to respond to paying customers in a timely manner. I'd like to get a result for the community if possible rather than turning a profit.

I haven't dug into the code to take a look, but there is a possibility that in order to fulfill the terms of the agreement to get a manufacturer key, the current S57 handling code might need to be modified (in case it stores unencrypted data on disk etc). I will need to look into whether I can submit back to the same git codebase as the main project or not. Given that it is GPLv2 I think it's possible to leave the code open, but not supply the encryption keys publicly (a clause was added to GPLv3 that requires this I believe).

In terms of implementation I'm thinking the S63 code would ideally work as if it was a filesystem layer below the S57 code. So the s57 code would operate as usual either pulling data from disk directly or via the S63 code. Again I've not looked at the code to see how this might work.

I will try to get the process started by inquiring about getting a manufacturer key. That should at least result in a document detailing the obligations that would need to be fulfilled.

[redcane]

Originally Posted by bdbcat

There is a non-trivial business opportunity here, clearly. One could build a business to license and resell S63 chart cells to OpenCPN users. Fully virtualized, no bricks, no mortar. I would fully support any such project. Heck, if I were not DevLead on OCPN, I might try it myself.

My current understanding is that users would still be buying charts from the existing chart sources, but those sources would be able to supply them locked to a users openCPN installation. In regards to what this venture would be supplying users you'd be able to/need to supply a closed module that handles the S-63 decryption (and is built with the private enyption keys). Yes I guess you could charge for this, but as I said in my previous post I think I'd rather tackle it with a community supported or non-profit model.

[bdbcat]

redcane...

Thanks for the comments.

My idea for a business model is in the way of "compensation" for the expected aggravation factor of working with a bureaucracy that has no concept of open source methodologies, and probably will not understand the not-for-profit model anyway. Also, some entity will need to own the key and sign the docs. Better a corp. than an individual, I think. Overhead grows....

Implementation detail:
There is a slow move afoot to merge the OCPN S57 code fully back into the most modern release of GDAL, from whence it came years ago. It will make OCPN code base smaller, offload some development effort to another upstream source, and make the linux repo managers happy.

So, an S63 encryption layer in the GDAL stack might make good sense here, and may find uses other than in OpenCPN as well. I imagine that we would need to have an OCPN PlugIn to manage the encryption of local SENC files, in order to meet the S63 terms of use.

Food for thought
Dave

[redcane]

Yes, I figured the non-profit model would offer some compensation for lost hours reading agreements. I guess it is an open question whether to charge for the end product, or take donations. I did assume some kind of legal entity would need to be formed to own keys. It would also allow the project to continue with other developers, and might help with contractual liability issues.

In regards to the technical details, this might rather change things a bit! I guess the code could still be built in the GDAL codebase, and it's under an X11/MIT license. This means it shouldn't be a problem to build a closed source version without having to supply license keys to end users. I'm just not sure how this is going to work in term of supplying it to end users. I guess we'd have to install a custom GDAL library on a users system, or statically link a custom library in an OpenCPN build.

It would be ideal if the key was locked to the GDAL library though, then you would potentially be able to run multiple different softwares on the the same chart via the same GDAL stack (since it has the unique key linked to it)!

[bdbcat]

redcane...

We could certainly start with a custom GDAL library delivered with the "OpenCPN S63 PlugIn Package", whatever else that might contain. Any custom GDAL code could/would drift upstream in the usual slow way, and someday become part of the GDAL mainstream. At least that is how the model should work.

But the thing definitely has two parts:
a) the reading of original S57 cells, encrypted by S63. Maybe GDAL based.
b) encryption/decryption of local OpenCPN SENC files at runtime, probably by OCPN PlugIn. Uses same key mechanism as S63, for simplicity.

Dave

[redcane]

Just to clarify - are the SENC files used internally be OpenCPN? It seems like there are multiple (device dependent) SENC formats, that are all based on a translation from S57. In fact it seems like some people purchase S63 charts through a third party that converts them to SENC for their particular device and they are then supplied in that format?

Aside from the (possible contractual) requirement to not leave unencrypted chart data from commercial charts on disk, I'm not sure why this would need to be encrypted/decrypted?

It makes sense to use S63 code for it if required though.