Problem statement. Here is my understanding of the problem you want to solve. Each customer has a 10-digit customer ID, which is privacy-sensitive and which you don't want stored or transmitted to the server: but you do want to be able to uniquely identify the customer. Got it.
Solution #1. Here is a fairly simple solution. Generate a cloaked identifier by iteratively hashing the 10-digit customer ID many times, say one million times. The number of times you iteratively hash it is a parameter that you can choose. I suggest you choose the parameter so that the entire iterative hashing process takes about one second or so. We are trying to make it expensive to recover the original 10-digit customer ID from the cloaked identifier.
When you enroll a new customer, you generate their cloaked identifier and store the cloaked identifier in the server app's database. When a customer installs a client app, the client app gets access to the 10-digit customer ID and iteratively hashes a million times to construct the cloaked identifier. This process takes about a second, but the client app never needs to do it again: it can store the cloaked identifier permanently.
When the client app wants to talk to your server app, it should connect to your server app over SSL/TLS and transmit the cloaked identifier over the SSL/TLS connection. The server can verify the validity of the cloaked identifier and use it to identify the customer. Your server app should use a standard SSL/TLS certificate, and the client app should verify this certificate.
Security analysis of solution #1. Solution #1 is a bit more secure than storing the 10-digit customer identifiers on the server, though please understand that it is not perfect. Let's say you have N customers and hence N cloaked identifiers stored on the server. An attacker who steals a copy of the server's database can recover all of the original customer IDs by building a mapping between 10-digit numbers and their million-fold hashes. It will take the attacker 1010 × 1,000,000 = 1016 ≈ 253 hash operations to build the entire mapping. This computation is feasible, but not trivial: it is not something you can do over the weekend on your home machine (it is more like hundreds of CPU-years of computation, so it is achievable with a large cluster, and probably achievable for thousands or tens of thousands of dollars, but not super-easy). Once the attacker builds the mapping, he can easily recover all N customer IDs.
This might be good enough for your purposes. If it is not, here is one slight improvement:
Solution #2. Don't store the cloaked identifier on the server; instead, store a salted hash of the cloaked identifier. The cloaked identifier is defined as before. But now, when you enroll a new customer, you generate the cloaked identifier, you generate a random salt for the customer, and you store (salt, Hash(salt, cloakedid)) on the server. You don't store a copy of the cloaked identifier. When the user installs a client app, the client app gets the 10-digit customer ID, computes the cloaked identifier, and sends the server a special request saying "I am new; here is my cloaked identifier, can you please send me my salt?" over a SSL/TLS connection to the server. The server takes the cloaked identifier I from the client, and for each pair (salt, h) in its database, it checks whether Hash(salt, I)=h. If yes, then it has found the matching entry for that customer and sends the customer's salt back to the client app. (The server does not retain the cloaked identifier.) The client app now stores the salt and the value Hash(salt, cloakedid). When the client app connects to the server in the future, instead of sending the cloaked identifier, it sends the value Hash(salt, cloakedid). This is sufficient to identify the customer.
Security analysis of solution #2. This is more secure than solution #1. An attacker who gets his hands on a copy of the server's database has to do 1016 hash operations per customer ID he wants to recover. To recover all N customer IDs, an attacker has to do 1016 × N hash operations; compare to solution #1, where only 1016 hash operations are needed.
On the other hand, solution #2 is more complicated and thus may be trickier to implement and deploy. Also, the server has to do a bit more work each time a new customer installs a new client app (the server has to do N hash operations each time a customer installs a new client app).