0

I'd like to build a rest service that will accept objects that has digital signature. This service has to support both xml and json data serialization formats. I'd like to use .Net core framework to build this service.

Controller has to check that digital signature is valid and dto properties were not modified.

This signature has to be stored (in the database) and used (if required) to verify that message was not changed while processing.

Sending flow is like below

  • client fills object with data
  • client calculates hash and sign it
  • client sends object and signature to the service
  • service calculate hash from object properties and verify signature
  • object and signature is stored in the db

The question is how to define and share hash calculation logic between service and client? Please note that client can be implemented using different framework or programming language.

UPD: Or, probably there is an alternative way to check data integrity that are sent by the client. Like Amazon has implemented.

I've thought that dto can have string GetHashData() method that will concatenate valuable dto properties to the string. Then hash can be calculated for this and is used to sign or to check the signature.

However having method in the dto object does not look good.

I can implement some helper class and use it in the rest service that to calculate hash for each object type. But this logic has to be implemented on the client side as well. It can make usage of the service a little bit tricky.

I know that both xml and json has digital signature, like XMLDSIG and JWS. But it makes digital signature to be dependent from the format that was used by the client to talk with service. I can not use JWS or XMLDSIG if object was deserialized and passed as parameter to the REST controller.

1

The question is how to define and share hash calculation logic between service and client? Please note that client can be implemented using different framework or programming language.

As the client and server can be written using completely different technologies, you can not assume that any code sharing will be possible. As a consequence, the best way to define the hash calculation logic is in an interface specification document.

How you then implement this specification in your server-side code is completely up to you. You can just assume that the client side will make its own, independent, implementation of the specification.

  • I'd like to check also is there an alternative way. Probably there is some technology to sign web requests, like Amazon has implemented. But independent from the data format used to serialize request body – oleksa Jun 20 at 13:25
  • @oleksa: If you find such a technology, you still have to write down in a specification that you are using that technology. – Bart van Ingen Schenau Jun 20 at 13:47
  • @oleksa If you look at the details of the Amazon approach, it's concatenating elements to form a UTF-8 string and the using calculating a HMAC. So it's basically as described in this answer: a specification. – JimmyJames Jun 20 at 19:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.