Share a public key from an app to verify authenticity of data submitted

Question

I'm quite new to information security topics and am looking for guidance to implement secure transmission of statistical data from an app to a server. In addition, I don't want any knowledge about the data stored on the server.

This is my approach:

1. A developer creates a key pair and places the public key in the app.
2. The app generates a public and a private key when launching for the first time. It sends the public key to the server and gets a user ID in return. Then it discards the generated public key.
3. Every time the app sends data, it does it by encrypting the data with the public key from the server and signing it with its own private key.
4. The developer can then retrieve the data for each user ID from the server and verify the authenticity with the public key stored with the user ID.

And here are my questions:

1. Is it enought to send the public key generated on the device once or should I use a more sophisticated scheme to verify that data is sent by this exact user? There is no login and I don't care who the user is. But I want to make sure an attacker cannot send wrong data by forging the user ID without being detected.
2. What should I do to detect missing data? It is okay if some data gets lost due to network issues. I am considering using ascending integers in the encrypted data. This would reveal if someone steals the private key and the current number from the app and sends wrong data.
3. Finally, are there some concrete implementations that an inexperienced user like me can use without messing up?

Answer 1

Question 1

MiTM types of attack can be easily avoid by implementing encryption and digital signature. Since you are encrypt and sign the data being send, and assuming client's device is not compromised, it is fair to say even the data was altered, you will know it if you implemented those thing right. You can harden your system by using TLS plus public key pinning, that way, even someone wants to intercept, the client will know because the certificate is different.

Question 2

You can't do much about it if you only use asymmetric cryptography and digital signature, for more details, look at https://security.stackexchange.com/a/31032/58501. However, if you willing to ask the client to type in a OTP which the master key will only know by both parties, and exchanged in a secure way. You can detect such attack even the private key is leaked since the OTP can change over time or by increasing counters, depend on which OTP you use. Take a look at RFC 4226 and RFC 6238 to get some idea from it. Note, the OTP generating machine should be differ than the communicating device, and no connection between them.

Question 3

It depends on what computer language you're using, you can try find an OpenPGP API or framework, this is the only software I know it can do what you want without much knowledge(it still require some learning, not as much as doing it from ground up). If you can't, you're out of luck since doing cryptographic stuff in a correct way requires a lot of steps and long time learning. E.g. you should encrypt the data first, then calculate the hash of it, sign it with the private key, pack all the stuff in one package, finally sent it to the server. These steps are mostly separated in a framework which you need to call each of them individually.