0

I am struggling for an entire week now, failing at meeting the encryption requirements of HERE traffic api, precisely TPEG API.

Steps to do:

<?xml version="1.0" encoding="UTF-8" ?>
<get-messages>
  <locations>
     <loc lat="52.55121" lon="13.16565"/>    
  </locations>
</get-messages>

This xml body must be enrypted, HERE API documents it as follows:

Encrypt and compress all traffic information requests:

  1. Compress the XML body using gzip.

  2. Calculate the length in bytes of the gzip file.

  3. Prepend the length of the gzipped data to the compressed body as a little endian 32 bit integer.

  4. Pad the combination of gziped content and length with zeros to make it evenly divisible by 16 bytes.

  5. Using AES 128, encrypt the resultant padded combination of content and length as follows: a) Create a random integer 16 bytes long. b) AES encrypt the result of step 4, in mode CBC using the integer generated in step 5.a as the initialization vector and the key from the InitSession response. Do not apply additional padding.

  6. Send the resulting block of AES encrypted data as an HTTP POST request, prepended by the integer generated in step 5.a as content type application/octet-stream to the URL in the initsession response

So many things are just unclear here, what is the desired result of the gziped xml? Base64? binary? What is the type of the 32 little endian int, binary?

The key has a length of 32 characters. Since AES128 only fits 16 bytes long keys, I assume the key must be interpreted as hex values. Do all values need to be defined as hex values?

What is the type of the IV? Hex? Text? Binary? What is the type of the encrypted result? Hex? Binary? Text? Base64?

The http header must contain content_type appilcation/octet-stream.

Yesyoor
  • 157
  • 1
  • 18
  • You asked the same question here: https://stackoverflow.com/questions/69181097/request-tpeg-data-with-here-tpeg-api but with more detail. Why post one with less? – Software Engineer Sep 20 '21 at 06:33
  • The first question has been answered by myself. The url provided was wrong. Now I wonder about the encryption, which is the next step in the process, therefor I created a new question. Reviewing the linked question I admit you are right. I can mark one as deleted if either one gets answered. Thanks for the effort! – Yesyoor Sep 20 '21 at 07:40
  • @SoftwareEngineer Sorry I got confused, this question has been answered by myself: https://stackoverflow.com/questions/69193286/here-api-request-tpeg-data-missing-query-parameter-v The question you linked in your comment was marked for deletion, because I was not sure about the copyrights of the images. I then posted this question without the images. I hope you can give me more details about the implementation. – Yesyoor Sep 20 '21 at 08:18
  • @SoftwareEngineer we tried out a lot of ways to encrypt the data, and confirmed the decryption, once implemented in c# and once done so with online tools. We also cross checked the results, still HERE TPEG API won't accept the result. Can you give us any hints on how the data should be send? – Yesyoor Oct 12 '21 at 09:45
  • 1
    little endian 32-bit is a 4-byte integer storing the length of gzipped content. Since you are using C#, it should be `uint` as stated [here](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/integral-numeric-types). All values - keys, IV, encryption result, etc. should be stored in `byte[]`. See [here](https://developer.here.com/documentation/tpeg-traffic/dev_guide/topics/quick-start.html#request-first__retrieve-traffic-info), the InitSession returns a hex key. – kiner_shah Oct 15 '21 at 10:08
  • 1
    @kiner_shah hey thanks a lot so far for the precise informations! I will try it out very soon and reply to your answer. – Yesyoor Oct 23 '21 at 13:55
  • 1
    @kiner_shah thank you very much, using Uint32 for the length has been the solution. Although BitConverter.isLittleEndian returned true and we used an Int32 before, it only works using Uint32. Finally we receive the binary data. If you post your answer as a solution I will upvote it. – Yesyoor Oct 26 '21 at 09:44
  • 1
    @kiner_shah We just realised that changing the int to UInt32 didn't change anything. In fact changing the hex key to bytes was the solution :) Thank you again for the help! – Yesyoor Oct 28 '21 at 12:24
  • 1
    Yeah, I was wondering why Int32 wouldn't work since it is also 4 bytes. Great to know bytes array worked. Glad to help :-) – kiner_shah Oct 29 '21 at 06:54
  • I have a complete solution to work this API. Let me know if you're interested and I can share it – Nagaraddi Mar 15 '22 at 08:53
  • @Nagaraddi we managed to get it to work, but thanks anyways! :) – Yesyoor Apr 22 '22 at 14:48

0 Answers0