It's good of you to recognize that it's useless to encrypt the number when the key is on the same server.
So don't put it on the same server.
When the SS# is received, take the last four digits and write them to a table. Now, as far as the web server is concerned, these four digits are ALL of the number that the web server knows or will ever know. If you want the customer to prove their identity and you ask them the last four digits, you can compare them against this field in the table.
When the SS# is received, encrypt it with a one-way public key (I use GPG for this) and store transfer the encrypted string to another server (which needs to be secure). Only the last four digits are written to the web server. When your boss needs to obtain reports, they come from the secondary server, not from the web server. If your boss says that's inconvenient, tell them "tough noogies - that's how it's done." If they still don't like it, then you send them to me.
The more I write, the more I realize that this is too big of a topic to cover correctly in an online help forum. You need a plan. You need to think of all the attack vectors and plan for them. Think of how you can make the secondary server receive the encrypted SS# data from the web server but not be able to send data out whether through smtp, ftp, ssh, telnet, http, or even Instant Messages.
