Unplanned
Last Updated: 29 Mar 2024 13:41 by ADMIN
Mark
Created on: 18 Jan 2019 15:57
Type: Feature Request
4
Apply a signature to a telerik trdp/trdx report file

I would like to formally request the ability to "sign" in some fashion a trdp/trdx file.  Note that if only the new file format is supported then that would be acceptable.

Basically, I would like to apply some signature that we could, if we so chose, read from the report file to verify that it was us that created or last modified the file.

If we need to use a separate tool to apply the signature other than the report designer, that would not be an issue.

The signature could be anything that Telerik/Progress decides we can use such as a code signing certificate, a strong name, etc.

Using the last modified time, or a hash value created from the current contents of the report file would not be a good solution as that would mean we would need to have a list of the hash values for each report and it would need to be updated every time the report is changed.
We are looking for something that could be applied to all reports that we create and that clients could not replicate.

This would need to be something that clients who we deploy the report files to cannot replicate and therefore if they modify the report file using the Telerik designer, it would remove that signature.  This way we can easily programmatically determine if the client has modified the report, and therefore prevent using it as if it is ours.

Note that we provide the ability to use custom reports in our application which are treated as separate from our core provided reports.  Also, I had posted to the forum asking if this is currently possible (https://www.telerik.com/forums/sign-telerik-reports).

Thank you.

15 comments
ADMIN
Ivan Hristov
Posted on: 29 Mar 2024 13:41

Hi Mark,

Thank you for bumping up the topic.

You are right, adding this functionality will bring value to the product, especially in terms of security.

I understand you might be disappointed that the feature is not included in our short-term plans and won't be a part of our next release. I will make sure to include it for evaluation in our next product planning session, which will happen late May. Based on the decision we take, the status of its corresponding public feedback item will be updated.

All best,

Ivan Hristov

Reporting Team

Mark
Posted on: 22 Mar 2024 20:02

I take it that you have not looked at this any further.

I still think this would be a great addition to your product.

Mark
Posted on: 26 Apr 2021 21:43

I have done a couple of quick tests of the app you provided and it appears to work well enough.  I have not cracked the code open to look inside at what you are doing to see how we would automate the validation.

Note that when I validate a trdx file that does not have a signature it tells me, but if I do the same for a trdp file, it throws an exception and changes the modified date of the file.

It seems to work fast which is great.

Thank you for all your hard work! :)

ADMIN
Mads
Posted on: 26 Apr 2021 06:56

Hello Mark,

We discussed this topic in the team. As part of the investigation for implementing this functionality, we created a sample console app that can create keys, and use them to sign and verify TRDX and TRDP reports. We would like to share this with you, though it's important to note that this is not any official Telerik release. 

Our team agrees that having this functionality is useful and would be a great addition to our product, though we are unsure if it should be implemented into the Standalone Report Designer, or kept as a separate tool. For now, this application only supports RSA encryption, which means using a key-pair. This does not mean we have decided not to support Code Signing Certificate, but that it might be supported at a later stage.

Currently, the application stores the produced hash-string inside a textbox. Having a field, like an attribute of the Report tag, to store the hash would be a great first step. If this would be applied in the future, that would make this sample-application I am now sharing incompatible, so please do not use this in your production environment.

It would be great if you had a look, and tested it to see what you think. Please share any feedback if you have.

Regards, Mads Progress Telerik

Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.

Attached Files:
ADMIN
Mads
Posted on: 20 Apr 2021 06:18

Hi Mark,

We will take into consideration using Code Signing Certificate. I will provide an update once we have discussed this further internally.

Regards, Mads Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Mark
Posted on: 13 Apr 2021 07:10

Hi Mads

It sounds a bit like unplanned is similar to our internal "To be Scheduled" status, although I imagine that could add extra undesired connotation.

I completely agree with your points regarding using RSA or a code signing certificate.
It is possible, however I think the likelihood is very low, that some may be concerned that the RSA private key could be compromised in some way such as being hacked or accidentally released.  Using a code signing certificate with the ability to timestamp it, would eliminate both the concern about expiry, and the possibility that the key is compromised.  However, I do think that would be asking a lot to do that, and unless it was not that difficult, I would not suggest going that far.
We have had private info accidentally released in the past, and while not critical, it was not desired.

Thank you very much for the clarification regarding everything.  Sorry for rambling on... :)
It is much appreciated.

Mark
Seradex Inc.

ADMIN
Mads
Posted on: 13 Apr 2021 06:55

Hi Mark,

Thanks for following this up and providing your feedback. I will go through the questions and try to reply and share our thoughts.

Where To Store The Hash

As we have looked into how to solve this, we have looked for places to store the hash-string. This can be done in many different ways, but if we were to implement functionality to sign and verify reports, it would probably be best to have a dedicated field to store it. And because TRDX reports and TRDP reports are so different, one idea is to have an XML attribute added to the <Report> tag inside the Report definition. This way it will stay consistent for both of the report-formats.

By having the hash-string stored as an XML attribute, it would also make sense to have the Standalone Report Designer preserve this attribute upon saving. There might be many reasons why it is not needed to preserve it, but I believe there are not many cons to preserving it. By keeping it, you could potentially confirm that the report has previously been hashed, but edited afterward.

Code Signing Certificate / Key-pair

By using a Code Signing Certificate there are some challenges as you mention like expiry and how to acquire such certificate. With RSA you can easily let users create their own key-pairs which does not expire. The creation of such keys can be part of the signing/verification functionality we are considering implementing. The key pairs consist of a private and a public key, which belongs to each other. The private key stays internal, sharing only with the developers that create the reports and need to sign them. The public key can be shared with anyone who wants to use it to verify the reports, but will not enable anyone to recreate a new valid hash-string.

Status Changed To Unplanned

The previous status was 'Under Review', which means we are looking into if we should approve or decline the request. This specific feature-request has been stuck at this previous status for some time, but has now been approved. Even though it has been approved, we do not have a specific plan for when it will be implemented.

I have spent some time looking into possible ways of implementing this feature and plan on presenting the ideas, based on my testing and our discussion, to the team. Once this is done I hope to have some more information to share on the plan forward.

Regards, Mads Progress Telerik

Тhe web is about to get a bit better! 

The Progress Hack-For-Good Challenge has started. Learn how to enter and make the web a worthier place: https://progress-worthyweb.devpost.com.

Mark
Posted on: 12 Apr 2021 15:44

Hi Mads

I want to thank you for your input on this and I hope my comments did not complicate things.

Note that just because we are already using a code signing certificate, it does not mean it has to be used here.  Also I was making comments, regarding certificate expiry, more about our companies internal processes than what we would require from Telerik.  I also thought it could be something that other companies would need to think about.

I was just wondering why the status was changed to unplanned.

I greatly appreciate all your work and input on this.

Thank you.
Mark
Seradex Inc.

Mark
Posted on: 07 Apr 2021 13:11

I can understand your idea about reverting the changes, but I would think that even a small change such as resizing or repositioning a control would cause a different hash to be generated and it would be difficult to completely undo that change once the user has closed the report.  I think it would be easier to simply obtain an original copy from us or from some kind of backup.

I asked about using a code signing certificate because we already use one in our product.  It does, however, beg the question, what would happen when the certificate expires or is otherwise replaced.  My guess is that we would need to deploy re-encrypted versions of our reports since we would need to update the public key that is used to decrypt that info.  That may be acceptable, but I am not certain.  I also do not want to complicate things for you either.

I appreciate your responses.

Thank you.

ADMIN
Mads
Posted on: 07 Apr 2021 11:03

Hi Mark,

As you mention, having the stored hash be persistent between edits is not really needed. Once the report is hashed and the hash-string is stored inside the report, any edits will, either way, invalidate the hash. But at least when the hash is still available in the report, you can perform the validation against it. The benefit would be that the hash will be created based on the content, meaning a client can open the report, save it to a new file without applying edits to it and still have the verification go through. In this approach, a client could also apply changes to a report, then revert all the changes and still have the verification succeed. 

I believe in your scenario there would not be much need for the public key. But this key could potentially be shared with 3rd parties, and they can use it to verify reports, without having the ability to create a new valid hash. RSA encryption works like this and will create a hash that is virtually impossible to replicate or recreate based on different content.

And adding the hash-string would change the hash. It could be replaced by an empty string when the hash is calculated and when the verification is performed to avoid this, then re-added once it's finished.

I believe this approach could make use of Code Signing Certificate, but this would require users to acquire a valid certificate from a Certificate Authority, if I am not mistaken? With RSA you can simply and quickly create a key pair in the application, then start using them immediately. 

Regards, Mads Progress Telerik

Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.

Mark
Posted on: 07 Apr 2021 07:32

In my original post I said I did not want the value persisted between edits.  With it being a signed hash I imagine it would not be a concern, but I'm not sure how that could be used to decrypt via a public key to get a hash value to verify the report.

The entire purpose is to quickly determine if the report that we are attempting to load was published by us or was modified by the client.

If the key is missing, we would have to make the assumption that it is not our file.  This would need to be done anyway as the client could simply replace the report file instead of just editing it.

That said if the validation was quick and performed by a Telerik method, at least partly, to abstract this, then I think it could work.  I understand how you are suggesting using a hash of the file, but encrypting it via a non-publicly available encryption to prevent others from being able to replicate it, and it because it is a hash, the odds of it being valid when copied to another file are low.  Perhaps having the ability to include the UTC file time in the hash would virtually eliminate all possibility of duplication, although that might make simply moving the file around difficult.  Is there a modification date property in the XML that could be used, or perhaps would be included...

I would think that including the resources in the signature would be the right thing to do.

If the xml is the definition of the report and we add a signature to that xml that is based on the hash of the xml and the resources, wouldn't that change the hash?  As long as that is addressed then I expect that it should work.

Could your proposal make use of a Code Signing Certificate for doing that encryption and possibly decryption somehow?  I only ask because it is the first thing I think of when signing files.

ADMIN
Mads
Posted on: 07 Apr 2021 07:01

Hello Ken and Mark,

We looked into this request lately and have discussed the possible ways to implement this.

I believe this would be best to solve with some asymmetric encryption so that a private and public key can be generated. The private key can then be used to create a signed hash based on the definition of the report and to verify that hash against the report-definition to confirm that they match. The public key can only verify the report. This way you would not need to store any table of individual hash-values for each report, but only store the keys.

The signed hash that is generated from the report-definition would need to be stored with the report somewhere. There is currently no designated place to store it. By storing it somewhere in the report-definition XML, it should be somewhere that is persistent and does not get removed when a Report is edited, then saved, in the Standalone Report Designer(SRD). So adding the hash-string as a comment would be removed when the report is edited in the SRD.

Hashing a TRDX XML report would be quite simple as it's only a text-based file. While TRDP reports are a compressed folder, containing the XML definition, in addition to storing resources as separate files. I assume that you would want the verify the content of both the report XML and its resources, right?

By solving this feature-request as mentioned above, I believe there are two steps required to complete it:

  1. Adding a dedicated spot within the Report-definition XML to store a signed hash-string. This tag or attribute would need to be left untouched by SRD, in the case where one of your clients decides to edit one of your reports.
  2. Create the tool, or add functionality into SRD, to generate a signed hash based on the report by using a private key, and verify a report based on a public/private key.

Do you believe this would work in your scenarios?

Regards, Mads Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

ken
Posted on: 16 Apr 2019 20:01

I second this request.  We also provide a set of base reports.  Our support team has spent time troubleshooting reports that were altered by customers and no longer work as expected. 

Currently they export the TRDX file and compare the hash to our base version.

I have a TODO to make the hash display in the application so they don't have to export.  But being able to programmatically determine by signature would be better.

Thanks,

Ken

Mark
Posted on: 21 Jan 2019 18:50

I forgot to mention about having the ability to read this signature.

A sample that demonstrates this would be appreciated, whether it uses a built in .NET method, or a new Telerik method that you create.

 

Thank you for considering this. 

ADMIN
Silviya
Posted on: 21 Jan 2019 08:23
Hi Mark,

Thank you for your input!

Regards,
Silviya
Progress Telerik
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items