I have worked in the past on medical applications running on portable devices that need to communicate with a central server, but need to also work when no network connection is present.

The first thing to do is to do a proper security analysis. What are the risks to data, and how are you managing to protect the data against those risks. e.g.

1. Sensitive data transfer of TCP network to the server.
2. Storage of sensitive data on the device
3. Identification of user on the device
4. Identification of device to the server
5. access to sensitive data on the device by an identified user.

What is appropriate will vary with the nature of the sensitive data, and the product involved, but to give you a guide, here were the answers for that medical product...

1. Data over the network was encrypted by SHA256, and where ever possible we used a private APN network which connected to the server data centre via a private leased line.

2. On the device we stored sensitive medical information encrypted by SHA256 but without any patient identifiers. Encryption key was device specific so data files could not be accessed by copying data to a different device.

3. Access to the software one the device was controlled by a 3 digit pin number. This was probably the weakest aspect, as patients then typically chose simple pins (e.g. 123 or 147)

4. Each device identified itself with a client certificate to the server, and then had to supply additional hardware provided identifiers to the server to validate the device matched the servers expectations. Only the server knew the identity of the patient that used that device, and server identification was all about confirming whether the device was authorised to connect to the server, and which device it was.

5. In our case, having access to past historic measurements was important to the patients, so patients could view their historic measurements if the device had successfully authenticated with the server in the past 24 hours, and its last successful socket connection had resulted in the device being authenticated.

I have worked in the past on medical applications running on portable devices that need to communicate with a central server, but need to also work when no network connection is present.

The first thing to do is to do a proper security analysis. What are the risks to data, and how are you managing to protect the data against those risks. e.g.

1. Sensitive data transfer of TCP network to the server.
2. Storage of sensitive data on the device
3. Identification of user on the device
4. Identification of device to the server
5. access to sensitive data on the device by an identified user.

What is appropriate will vary with the nature of the sensitive data, and the product involved, but to give you a guide, here were the answers for that medical product...

1. Data over the network was encrypted by AES-256, and where ever possible we used a private APN network which connected to the server data centre via a private leased line.

2. On the device we stored sensitive medical information encrypted by AES-256 but without any patient identifiers. Encryption key was device specific so data files could not be accessed by copying data to a different device.

3. Access to the software one the device was controlled by a 3 digit pin number. This was probably the weakest aspect, as patients then typically chose simple pins (e.g. 123 or 147)

4. Each device identified itself with a client certificate to the server, and then had to supply additional hardware provided identifiers to the server to validate the device matched the servers expectations. Only the server knew the identity of the patient that used that device, and server identification was all about confirming whether the device was authorised to connect to the server, and which device it was.

5. In our case, having access to past historic measurements was important to the patients, so patients could view their historic measurements if the device had successfully authenticated with the server in the past 24 hours, and its last successful socket connection had resulted in the device being authenticated.