ModelicaSpecification
ModelicaSpecification copied to clipboard
modelica
Suggestion for a standard for encryption, licensing and packeting of libraries
Reported by jmattsson on 18 Dec 2015 17:04 UTC To enable proprietary Modelica libraries to be compatible with multiple tools, Modelon and Wolfram has worked together on a suggestion for a new standard for encryption, licensing and packeting of Modelica libraries. The suggested standard describes:
- A protocol for interaction between a Modelica tool, and an executable that is provided in the library, that can handle decryption and licensing.
- A file with meta-data about the library, for easier access without decryption and/or parsing of the library, as well as information about the executable mentioned above.
- A format for packeting Modelica libraries in a single file for distribution.
The suggested standard is described in the attached file "Licensing & Encryption v1.pdf".
Migrated-From: https://trac.modelica.org/Modelica/ticket/1868
Comment by beutlich on 18 Dec 2015 20:15 UTC See also #1282 for a previous discussion.
Comment by dag on 21 Dec 2015 10:56 UTC Based on your experience, what is the ECCN number of the library vendor executable? That is an important question as it could potentially affect our classification.
Comment by hubertus on 22 Dec 2015 15:26 UTC Dag, because Dymola already has the same type of encryption software embedded, it should have the same ECCN code already now. The ECCN number for encryption software is 5D002. This is probably rightly classified as "Cryptographic enabling software, 5D002.d. In any case, it would be strange if it changed the classification for Dymola, which has the same functionality today.
Comment by dag on 22 Dec 2015 21:01 UTC Hubertus, you maybe underestimate the complexity of this issue. We can only manage because we have dedicated experts in the field.
Dymola is not regarded as cryptographic software because it does not decrypt files with arbitrary encryption keys. On the contrary, every library encrypted by Dymola can be decrypted by any Dymola program, but you need a license key of course.
So I interpret your reply such that the library vendor executrable, if it supports encryption, would be 5D002. Next question: what does that mean with regards to export control and where/how you can sell your software?
Comment by hansolsson on 4 Jan 2016 17:20 UTC Regarding the non-encryption parts: I remember that this was discussed before, and one previous comment form #1152 was "if you want to distribute a Modelica library in one file, why not just zip the corresponding directory in the file system"?
Meaning:
- Allow manifest files (etc) in Modelica directories
- Specify that we can distribute a zipped version of one or more Modelica directories (as in this proposal)
I can see some reasons for having additional restrictions on the zipped directories, but not for having unique contents in the zip-archives.
For the encryption part I need to study it in more detail.
Comment by hansolsson on 5 Jan 2016 09:17 UTC I believe this supersedes #536 and #1152 (obviously the proposals are different), and would thus to close them as duplicates - and if necessary include relevant parts of that discussion (as I tried to do above).
Comment by pharman on 5 Jan 2016 10:04 UTC Replying to [comment:5 hansolsson]:
Regarding the non-encryption parts: I remember that this was discussed before, and one previous comment form #1152 was "if you want to distribute a Modelica library in one file, why not just zip the corresponding directory in the file system"?
Meaning: * Allow manifest files (etc) in Modelica directories * Specify that we can distribute a zipped version of one or more Modelica directories (as in this proposal)
This was proposed and discussed in #132, and a working implementation was shown at a design meeting in 2009.
Replying to [comment:6 hansolsson]:
I believe this supersedes #536 and #1152 (obviously the proposals are different), and would thus to close them as duplicates - and if necessary include relevant parts of that discussion (as I tried to do above).
The resource bundling described in #132 and #1152 does form part of this ticket, I don't think #536 does though.
Comment by hansolsson on 5 Jan 2016 12:41 UTC Replying to [comment:7 pharman]:
Replying to [comment:6 hansolsson]:
I believe this supersedes #536 and #1152 (obviously the proposals are different), and would thus to close them as duplicates - and if necessary include relevant parts of that discussion (as I tried to do above).
The resource bundling described in #132 and #1152 does form part of this ticket, I don't think #536 does though.
You are right that I should have included #132 (some parts of it were added earlier to the specification). Ticket #536 has some parts that are superseded by this ticket, and the other parts would need to be updated.
The reason I didn't find #132 is that we have many open tickets, and the idea with closing more or less duplicate tickets is to make it easier to find the relevant ones.
Comment by hansolsson on 25 Jan 2016 15:53 UTC Apart from the issue with export control and previous comments I see two items that could be improved with minimal effort:
- The “library vendor executable” naming is similar to “vendor daemon” for FlexLM, but suggests that it is developed by the library vendor - and not by 3rd party. I would suggest renaming it to clarify its goal and give more information at the start: “Decryption executable” – the library vendor provides this program, and it can be internally developed and/or sub-licensed.
- Inside “encryption” in addition to “executable” allow “file”, or better: a group “file” with “path” and something like “key” – to identify the tool. The idea is to use this for existing encrypted libraries; and allow them to co-exist inside the same structure:
- Supporting this alternative makes it straightforward to convert existing encrypted libraries to this format - and thus getting the other benefits. Having a non-standardized variant for handling this (or hack like having the decryption executable just write the encrypted file as is) would be sub-optimal.
- Tool-vendors can ignore this addition - unless they already have their own encrypted file-format (and in that case it should be easy to support).
- If one tool-vendor only supports encrypted file-formats, and another only the new hand-shaking both versions of encryption can co-exist in the same zip. Clearly this (and/or multiple encrypted file formats) is inefficient - and thus library providers should naturally migrate from that solution.
Note that this addition doesn't create any new tool-vendor lockin - since the decryption executable already maintains a list of trusted tool-vendors.
I'm aware the "decryption executable" doesn't fully capture the licensing part of the executable, but I couldn't find a better name.
Comment by jmattsson on 27 Jan 2016 11:26 UTC Replying to [comment:5 hansolsson]:
Regarding the non-encryption parts: I remember that this was discussed before, and one previous comment form #1152 was "if you want to distribute a Modelica library in one file, why not just zip the corresponding directory in the file system"?
Meaning: * Allow manifest files (etc) in Modelica directories * Specify that we can distribute a zipped version of one or more Modelica directories (as in this proposal)
I can see some reasons for having additional restrictions on the zipped directories, but not for having unique contents in the zip-archives.
If I understand correctly, you want the additions described to be allowed both in the extracted and the zipped code? That is the intention in the proposal, and it is required that the zip file is extracted with all contents. I did not specifically write that the Modelica specification should be changed partly because it is my understanding that adding such a directory is currently allowed, and partly because I wanted this proposal to be usable without specification changes.
Comment by hansolsson on 27 Jan 2016 12:42 UTC Replying to [comment:10 jmattsson]:
If I understand correctly, you want the additions described to be allowed both in the extracted and the zipped code? That is the intention in the proposal,
Yes, and good that we agree on this.
and it is required that the zip file is extracted with all contents.
You are right the proposal requires this, and I didn't realize before - and it is not clear that this is desired.
As an example could a small library with thousands of resources such as png-files for the documentation, and a few tables. A tool could automatically unzip the images when needed and tables based on ModelicaServices.ExternalReferences.loadResource calls.
A manifest file additionally enable tools to find information (e.g. version information) without having to unzip and read other files (e.g. mo-files).
Thus I think we should consider removing this restriction, and instead state which parts must be unzipped to make the decryption work. Obviously the encrypted file and the executable itself, and as I understand also the directory of the executable - but do we need more?
I'm not certain that we will do a partial unzipping in Dymola (since disk-space and bandwidth is getting more plentiful), just that I think it would be good to consider - and I think it will be straightforward to specify if we do it early.
I did not specifically write that the Modelica specification should be changed partly because it is my understanding that adding such a directory is currently allowed, and partly because I wanted this proposal to be usable without specification changes.
It's true that it is allowed, and we can start supporting this without changes in the specification.
However, I still think this is something that should be in the specification.
Comment by jmattsson on 27 Jan 2016 13:08 UTC Replying to [comment:11 hansolsson]:
Thus I think we should consider removing this restriction, and instead state which parts must be unzipped to make the decryption work. Obviously the encrypted file and the executable itself, and as I understand also the directory of the executable - but do we need more?
That requirement is there to make the specification easier to understand and implement. If there is consensus for a more precise requirement, then I have no problem with that. My initial thought was that the decryption executable should read the encrypted files directly from the zip file, but we dropped that because we didn't want to require that it can handle both reading from the archive and from a directory structure. We thought that some tools might need to unzip the entire archive, thus requiring the decryption executable to handle that case as well.
It could work to simply require that the entire ".library" directory is unzipped before starting the decryption executable, plus that any file that is asked for with the FILE command must be unzipped (and in the correct place) before the command is sent. That would allow both tools that want to unzip everything at once and tools that want to unzip as little as possible, without making the decryption executable harder to implement.
It's true that it is allowed, and we can start supporting this without changes in the specification.
However, I still think this is something that should be in the specification.
My preference would also be to incorporate this into the Modelica specification. We just wanted to make it possible for it to work with the current spec.
Comment by dag on 19 Feb 2016 10:02 UTC I suggest we schedule a break-out session on this topic during the meeting in Linköping in March.
It would be great if one of the proposers could give a presentation of the complete scenario, not only the internals but the whole picture of distribution of libraries, licensing models, distribution of license keys, how it will be managed by the customer's organization, etc.
Export control is still an issue, so we need to discuss that too.
Comment by jmattsson on 19 Feb 2016 13:58 UTC Replying to [comment:13 dag]:
I suggest we schedule a break-out session on this topic during the meeting in Linköping in March.
I agree.
It would be great if one of the proposers could give a presentation of the complete scenario, not only the internals but the whole picture of distribution of libraries, licensing models, distribution of license keys, how it will be managed by the customer's organization, etc.
I'll prepare a presentation.
Comment by hansolsson on 7 Mar 2016 13:24 UTC One additional minor issue - it would be desirable that a tool could have more than one public/private SSL-key pairs. It wasn't clear that this is supported.
This just has a minor impact on the hand-shaking as far as I understand.
Two reasons:
- If existing keys would be compromised for a tool it can introduce new keys, while allowing existing decryption executables to continue with the old key.
- Companies might merge.
Comment by hansolsson on 7 Mar 2016 14:11 UTC Note: The operations specified in Modelica spec (ExportSource and ExportBinary) are not handled - since they should be in the authorization-file; and the new format does not have an authorization file.
It can be handled in various ways: e.g. just having an authorization file encrypted in the library (seems redundant), or answering some specific query (so asking for "Operations" instead of "package.moc" - even if there is no "Operations" file).
The idea in the Modelica Spec is that ExportSource could be depend on the specific user; so if using an authorization file it would be different contents for different users - which is contrary to the goal of simple distribution of libraries.
Comment by otter on 7 Mar 2016 14:12 UTC More information on protection is provided in: IEEE Std 1364™-2005 IEEE Standard for Verilog® Hardware Description Language http://staff.ustc.edu.cn/~songch/download/IEEE.1364-2005.pdf(http://staff.ustc.edu.cn/%7Esongch/download/IEEE.1364-2005.pdf)
Hello everyone,
Bosch Rexroth is very interested in a standardized encryption (tool-independent) for Modelica. I attached a file (draft) which compares the possibilities of VHDL-AMS (IEEE Std 1076.1-2017) and the Modelica specification 3.4 including the idea provided by Jesper Mattsson in this ticket. Maybe it can be a good starting points for further discussions, since also LTX GmbH is interested in a standardized encryption and licensing mechanism.
Best regards, Andreas
Hello everyone,
Note that I fully agree with this potential initiative :-) There are now many valuable tools supporting Modelica, used by several of our design partners. It would be a much more efficient way to exchange models than current FMI (which has many limitations vs Modelica), in particular with simulation of complex "physical" models (highly non-linear, with events, clocks ...) of natively acausal models (at boundaries ...) I have currently the issue, waiting desperately FMI 3.0 to solve partially the problem. A standardization of "encryption, licensing and packeting of libraries" would be much better.
Regards,
Eric Thomas
Just a reminder that the issue about export control has not been resolved. Currently, a tool such as Dymola is not regarded as sensitive because it does not allow user-defined encryption keys (i.e. the .moe file is just a proprietary binary file format). Adding functionality that changes the export classification could have far-reaching consequences.
Question to other tool vendors: what is your analysis of the impact on export classification?
I talked to a DLR lawyer. My understanding:
- Sending an encrypted library is allowed (no export control permission needed).
- Sending with the library an executable software that decrypts the library for a tool, means that decryption software is exported, and such a process has to be checked with regards to export control regulations in the respective country of the library vendor that exports this software. In the EU, this is allowed (so no export control permission is needed), due to exception "5A002, technical notes, 2e: Digital rights management including the execution of copy-protected software" in ANNEX I, Part VII, Category 5 of dual-use items (German version of the existing regulation: (http://www.bafa.de/SharedDocs/Downloads/DE/Aussenwirtschaft/afk_gueterlisten_dual_use_anhang_1_kategorie_5_teil_2.pdf?__blob=publicationFile&v=4), page 18; English version of the regulation that soon will be replace the existing one: (https://ec.europa.eu/transparency/regdoc/rep/3/2018/EN/C-2018-6511-F1-EN-ANNEX-1-PART-7.PDF), page 18.
So, to summarize, the proposed approach seems to be uncritical with regards to EU export control regulations.
So, to summarize, the proposed approach seems to be uncritical with regards to EU export control regulations.
Maybe so, but that possibly does not help us because we also have to handle US legislation. Martin, could you check with your lawyer what applies when you export software to/from the USA?
The legal department at Wolfram Research in the US makes the same interpretation as Martin's DLR lawyer, that is, that the proposed design would also be OK with US laws.
Henrik
On 2018-11-12, at 12:33, Dag Brück [email protected] wrote:
So, to summarize, the proposed approach seems to be uncritical with regards to EU export control regulations.
Maybe so, but that possibly does not help us because we also have to handle US legislation. Martin, could you check with your lawyer what applies when you export software to/from the USA?
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/modelica/ModelicaSpecification/issues/1868#issuecomment-437847766, or mute the thread https://github.com/notifications/unsubscribe-auth/AYH1P1Iu-ZEKOSrYImD5F3KCR51217ejks5uuVxxgaJpZM4YNXjw.
The legal department at Wolfram Research in the US makes the same interpretation as Martin's DLR lawyer, that is, that the proposed design would also be OK with US laws. Henrik
Dear Henrik, I'm not sure if I understood your message correctly: Are you saying, that there are similar exceptions for U.S. legistlation? Meaning, it would be OK to deliver the encryption/decryption tool together with the library?
Yes, the preliminary response based on the following brief summary is that it would be OK:
In the current proposal for the standard, the encryption of a Modelica library is handled by a binary that is distributed with the library. That is, SystemModeler wouldn't need to deal with encryption/decryption at all as long as the user is using libraries built by another software. The potentially sensitive part would be to allow SystemModeler to package a library with encryption, since SystemModeler would then need to both encrypt the library content, and also include a small binary for decryption inside the library package.
I take it as a preliminary response since it is only based on the brief summary above, and not based on a complete proposal which is in "under evaluation". Please indicate if there was any key aspect of the proposal that I forgot to mention.
Henrik
On 2018-11-19, at 12:06, Leo Gall [email protected] wrote:
The legal department at Wolfram Research in the US makes the same interpretation as Martin's DLR lawyer, that is, that the proposed design would also be OK with US laws. Henrik
Dear Henrik, I'm not sure if I understood your message correctly: Are you saying, that there are similar exceptions for U.S. legistlation? Meaning, it would be OK to deliver the encryption/decryption tool together with the library?
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/modelica/ModelicaSpecification/issues/1868#issuecomment-439855893, or mute the thread https://github.com/notifications/unsubscribe-auth/AYH1P5rHJjRC7-6coxwa2wE0FUyEHCSFks5uwpDLgaJpZM4YNXjw.
Thank you for the clarification. I really take this as an informal first information, as it would need to be checked by several lawyers, anyways.
So, do I interpret correctly, that the Library Vendor then needs to deal with the Export Control issues. A Modelica Tool would just act as an "importing" tool with an API and therefore does not have to worry about export control, as long as the library is not delivered bundled together with the Modelica tool?
New revision of the proposal, mostly clarity changes and a couple of minor protocol tweaks: Specification_v1_r2.pdf When this was first presented, Hans asked for support for opening a library directly from a .mol file without extracting it first. I think that this is a good idea, but have not had time to finish incorporating it in the proposal.
As for the export control, I can only comment that there are several different kinds of encryption and decryption involved. Both the Modelica tool and the executable from the library vendor would be including an implementation of TLS. This is also true for every internet browser on the market. The executable from the library vendor would also include code to decrypt files with a hard-coded key.
Additionally, a Modelica tool could include functionality for encrypting user libraries. In this case there would be several different possible approaches for setting that up, that could have very different consequences for export control.
I took a look at the Verilog link provided by Martin Otter, and while it is both rather general and flexible, it does require specific language support. In their case they use pragma, but in our case I guess we would specify annotations for that purpose. They define the encryption process using embedded directives in the source code. They require the receiving tool to handle decryption, and place licensing in a separate binary. I'm not clear on how the licensing binary is authenticated.
To use it we would still need to make some changes to make it fit into Modelica. To migrate any existing libraries into the resulting format would require adding annotations, probably to the top class of each Modelica file in the library.