Best practice to SSL Pinning in Flutter, fetch the certificate every time? or storing it in assets? - flutter

I went down the rabbit hole reading about SSL Pinning and how to implement it in Flutter, And I have two questions:
Is it secure to store (.pem) certificate file in assets? And if not, where to store it?
Is it secure and better practice to hit on the server on app load and get the certificate from there instead of storing it in app
I'm currently storing the certificate file in assets and fetching the path to it from app_settings.json using GlobalConfiguration().getValue() method.

That's how it usually works AFAIK
In this case the first API call isn't protected from MITM attack and SSL pinning purpose becomes broken
We used this plugin while implemented SSL pinning in our app (our client used Dio).
To implement this plugin you need to find corresponding fingerprint of your server certificate:
Click "lock" icon at the url address line
"Connection is secure"
"Certificate is valid"
General
Look for SHA-256 fingerprint at the Fignerprints section
Then you need to write this fingerprint into a constant list in your app to be used by the plugin.
The check should happen for EACH request you send because this is the main security purpose of SSL pinning - to check whether somebody modifies the request in the middle, between a server and a client. As per using Dio, you can use InterceptorWrapper to perform checks. The checker will look like:
class SslPinningInterceptor extends InterceptorsWrapper {
#override
Future<void> onRequest(
RequestOptions options,
RequestInterceptorHandler handler,
) async {
try {
// if the fingerprints do not match the plugin will throw a PlatformException
// SslPinningPlugin.check
// you can perform handler.next here because the exception hasn't been thrown
} on PlatformException catch (_) {
// you can perform handler.reject because check hasn't passed
}
}
#override
void onResponse(Response response, ResponseInterceptorHandler handler) {
// handler.next
}
#override
void onError(DioError err, ErrorInterceptorHandler handler) {
// handler.next
}
}

Your Problem
Is it secure to store (.pem) certificate file in assets? And if not, where to store it?
No where in the app is secure to store it because it's easy to extract via static binary analyses. The attacker will take the binary de-compile it with one of the many open-source tools out there, for example MobSF - Mobile Security Framework:
Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.
In a series of articles about Mobile API Security I show how to use MobSF to extract an API key, but the principle would be the same to extract a pem certificate. To have an idea on how MobSF can be used to decompile your app take a look to the article How to Extract an API key from a Mobile App with Static Binary Analysis:
The range of open source tools available for reverse engineering is huge, and we really can't scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.
During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.
TOFU (Trust on First Use)
Is it secure and better practice to hit on the server on app load and get the certificate from there instead of storing it in app
Not recommended to trust on the first usage, because you are trusting to retrieve the certificatie on the first API request made by your mobile app, thus making it easier for an attacker to bypass your pinning by MitM attack this first request and provide instead it's own certificate.
Possible Solutions
I really don't recommend you to store the certificate in your mobile app, neither I recommend to use a PEM certificate to perform pinning due its operational complexities and how easy is to get it stolen, instead I recommend you to use public key pinning, where you pin to the hash of leaf, intermediate or root certificate, thus you only need to change pinning on your app when the pinned certificate its renewed with a different private key. Another benefit it's that your PEM certificate it's not anymore for grab by attackers and the public key hash used for pinning it's not a secret, after all it's an hash of the public key.
Using the PEM Certificate
Now, if you insist in going down this root of using a PEM certificate then you need a mechanism to only deliver the PEM certificate to the mobile app when it's not running in a compromised device (rooted, jail broken), not running on an emulator, no debugger attached, not under a MitM attack, not being instrumented at runtime by Frida or similar, and that the mobile app itself is the same exact one that you uploaded to the official store, not a repackaged/cloned one. In other words you need to attest the device and app integrity before you return the PEM certificate from your server, as you suggested in 2:
Is it secure and better practice to hit on the server on app load and get the certificate from there instead of storing it in app
Read more about this approach in this answer to the question How to use an API from my mobile app without someone stealing the token where you will secure the PEM certificate as I suggest to secure the API token, by using a Runtime Secrets Protection.
Public Key Pinning
Did you considered to perform certificate pinning through the public key (not private, like the pem file) of the certificate? Android and iOS support this via configuration
Android docs:
Normally, an app trusts all pre-installed CAs. If any of these CAs were to issue a fraudulent certificate, the app would be at risk from an on-path attacker. Some apps choose to limit the set of certificates they accept by either limiting the set of CAs they trust or by certificate pinning.
Certificate pinning is done by providing a set of certificates by hash of the public key (SubjectPublicKeyInfo of the X.509 certificate). A certificate chain is then valid only if the certificate chain contains at least one of the pinned public keys.
iOS docs:
If your app sends or receives data over the network, it’s critical to preserve the privacy and integrity of a person’s information and protect it from data breaches and attacks. You should use the Transport Layer Security (TLS) protocol to protect content in transit and authenticate the server receiving the data.
When you connect through TLS, the server provides a certificate or certificate chain to establish its identity. You can further limit the set of server certificates your app trusts by pinning their public-key identities in your app. Here’s how to get started.
For example, to generate the config for Android and iOS you can use the Mobile Certificate Pinning Generator online tool:
Android App Example:
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<domain-config>
<domain includeSubdomains="true">approov.io</domain>
<pin-set expiration="2023-07-21">
<pin digest="SHA-256">INBbf7pLOYb+mX9IcJDaUPxo6DSqKObPtdy+uT92ccQ=</pin>
</pin-set>
</domain-config>
</network-security-config>
iOS App Example:
<key>NSAppTransportSecurity</key>
<dict>
<key>NSPinnedDomains</key>
<dict>
<key>approov.io</key>
<dict>
<key>NSIncludesSubdomains</key>
<true/>
<key>NSPinnedLeafIdentities</key>
<array>
<dict>
<key>SPKI-SHA256-BASE64</key>
<string>INBbf7pLOYb+mX9IcJDaUPxo6DSqKObPtdy+uT92ccQ=</string>
</dict>
</array>
</dict>
</dict>
</dict>
You can check in more detail how its done for Android on the article
Securing HTTPS with Certificate Pinning:
In order to demonstrate how to use certificate pinning for protecting the https traffic between your mobile app and your API server, we will use the same Currency Converter Demo mobile app that I used in the previous article.
In this article we will learn what certificate pinning is, when to use it, how to implement it in an Android app, and how it can prevent a MitM attack.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.

Related

Flutter Security

I am creating a Flutter app which uses Node Js server API. For the authorization I decided to use JWT with private/public keys. Communication between Server and mobile client uses HTTPS. Flutter app stores the token in a keychain (ios) or a keystore (android). My question is related to the need of the additional security measures implementations. I am wondering if the following points are required:
Verification of the server responses with public key by checking the token to identify the server
Verification of the client requests with the private key on the server side (client signs the token with public key)
Are these really needed in order to avoid man in the middle attacs? My objection is related to the performance related to signing/verifying tokens for each communication.
Thank you
I've used JWT our mobile apps for security and these apps had taken the security test(3.party company). The company says: secret your stored token or any keys.
And we know doesn't enough just JWT security. We wrote a custom encrypted algorithm to hide JWT (like sha-1) so we encrypt JWT to this.( you must write encryption code client-side & backend side)
Normal jwt : eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
After encriypt: xxs{4=-23dasdxe3 (example)
We passed the security rules with this solution.

Mobile app/API security: will a hardcoded access key suffice?

I'm building a mobile app which allows users to find stores and discounts near their location. The mobile app gets that information from the server via a REST API, and I obviously want to protect that API.
Would it be enough to hardcode an access key (128 bit) into the mobile app, and send it on every request (enforcing https), and then check if it matches the server key? I am aware of JWT, but I believe using it or other token-based approach will give me more flexibility but not necessarily more security.
As far as I can see the only problem with this approach is that I become vulnerable to a malicious developer on our team. Would there be a way to solve this?
First, as discussed many times here, what you want to achieve is not technically possible in a way that could be called secure. You can't authenticate the client, you can only authenticate people. The reason is that anything you put into a client will be fully available to people using it, so they can reproduce any request it makes.
Anything below is just a thought experiment.
Your approach of adding a static key, and sending it with every request is a very naive attempt. As an attacker, it would be enough for me to inspect one single request created by your app and then I would have the key to make any other request.
A very slightly better approach would be to store a key in your app and sign requests with it (instead of sending the actual key), like for example to create a hmac of the request with the key and add that as an additional request header. That's better, because I would have to disassemble the app to get the key - more work which could deter me, but very much possible.
As a next step, that secret key could be generated upon the first use of your app, and there we are getting close to as good as this could get. Your user installs the app, you generate a key, store it in the appropriate keystore of your platform, and register it with the user. From then on, on your backend you require every request to be signed (eg. the hmac method above) with the key associated with your user. The obvious problem is how you would assign keys - and such a key would still authenticate a user, and not his device or client, but at least from a proper keystore on a mobile platform, it would not be straightforward to get the key without rooting/jailbraking.But nothing would keep an attacker from installing the app on a rooted device or an emulator.
So the bottomline is, you can't prevent people from accessing your api with a different client. However, in the vast majority of cases they wouldn't want to anyway. If you really want to protect it, it should not be public, and a mobile app is not an appropriate platform.
YOUR PROBLEM
Would it be enough to hardcode an access key (128 bit) into the mobile app, and send it on every request (enforcing https), and then check if it matches the server key?
Well no, because every secret you hide in a mobile app, is not anymore a secret, because will be accessible to everyone that wants to spend some time to reverse engineer your mobile app or to perform a MitM attack against it in a device he controls.
On the article How to Extract an API key from a Mobile App by Static Binary Analysis I show how easy is to extract a secret from the binary, but I also show a good approach to hide it, that makes it hard to reverse engineer:
It's time to look for a more advanced technique to hide the API key in a way that will be very hard to reverse engineer from the APK, and for this we will make use of native C++ code to store the API key, by leveraging the JNI interface which uses NDK under the hood.
While the secret may be hard to reverse engineer it will be easy to extract with a MitM attack, and that is what I talk about in the article Steal that API key with a MitM Attack:
So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.
If you read the article you will learn how an attacker will be able to extract any secret you transmit over https to your API server, therefore a malicious developer in your team will not be your only concern.
You can go and learn how to implement certificate pinning to protect your https connection to the API server, and I also have wrote an article on it, entitled Securing Https with Certificate Pinning on Android:
In this article you have learned that certificate pinning is the act of associating a domain name with their expected X.509 certificate, and that this is necessary to protect trust based assumptions in the certificate chain. Mistakenly issued or compromised certificates are a threat, and it is also necessary to protect the mobile app against their use in hostile environments like public wifis, or against DNS Hijacking attacks.
Finally you learned how to prevent MitM attacks with the implementation of certificate pinning in an Android app that makes use of a network security config file for modern Android devices, and later by using TrustKit package which supports certificate pinning for both modern and old devices.
Sorry but I need to inform you that certificate pinning can be bypassed in a device the attacker controls, and I show how it can be done in the article entitled Bypass Certificate Pinning:
In this article you will learn how to repackage a mobile app in order to make it trust custom ssl certificates. This will allow us to bypass certificate pinning.
Despite certificate pinning can be bypassed it is important to always use it to secure the connection between your mobile app and API server.
So and now what, am I doomed to fail in defending my API server... Hope still exists, keep reading!
DEFENDING THE API SERVER
The mobile app gets that information from the server via a REST API, and I obviously want to protect that API.
Protecting an API server for a mobile app is possible, and it can be done by using the Mobile App Attestation concept.
Before I go in detail to explain the Mobile App Attestation concept is important to we first clarify an usual misconception among developers, the difference between the WHO and the WHAT is accessing your API server.
The Difference Between WHO and WHAT is Accessing the API Server
To better understand the differences between the WHO and the WHAT are accessing an API server, let’s use this picture:
The Intended Communication Channel represents the mobile app being used as you expected, by a legit user without any malicious intentions, using an untampered version of the mobile app, and communicating directly with the API server without being man in the middle attacked.
The actual channel may represent several different scenarios, like a legit user with malicious intentions that may be using a repackaged version of the mobile app, a hacker using the genuine version of the mobile app, while man in the middle attacking it, to understand how the communication between the mobile app and the API server is being done in order to be able to automate attacks against your API. Many other scenarios are possible, but we will not enumerate each one here.
I hope that by now you may already have a clue why the WHO and the WHAT are not the same, but if not it will become clear in a moment.
The WHO is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
OAUTH
Generally, OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.
OpenID Connect
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
While user authentication may let the API server know WHO is using the API, it cannot guarantee that the requests have originated from WHAT you expect, the original version of the mobile app.
Now we need a way to identify WHAT is calling the API server, and here things become more tricky than most developers may think. The WHAT is the thing making the request to the API server. Is it really a genuine instance of the mobile app, or is a bot, an automated script or an attacker manually poking around with the API server, using a tool like Postman?
For your surprise you may end up discovering that It can be one of the legit users using a repackaged version of the mobile app or an automated script that is trying to gamify and take advantage of the service provided by the application.
Well, to identify the WHAT, developers tend to resort to an API key that usually they hard-code in the code of their mobile app. Some developers go the extra mile and compute the key at run-time in the mobile app, thus it becomes a runtime secret as opposed to the former approach when a static secret is embedded in the code.
The above write-up was extracted from an article I wrote, entitled WHY DOES YOUR MOBILE APP NEED AN API KEY?, and that you can read in full here, that is the first article in a series of articles about API keys.
Mobile App Attestation
The role of a Mobile App Attestation solution is to guarantee at run-time that your mobile app was not tampered with, is not running in a rooted device, not being instrumented by a framework like xPosed or Frida, not being MitM attacked, and this is achieved by running an SDK in the background. The service running in the cloud will challenge the app, and based on the responses it will attest the integrity of the mobile app and device is running on, thus the SDK will never be responsible for any decisions.
Frida
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
xPosed
Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo.
MiTM Proxy
An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
On successful attestation of the mobile app integrity a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud are aware. In the case of failure on the mobile app attestation the JWT token is signed with a secret that the API server does not know.
Now the App must sent with every API call the JWT token in the headers of the request. This will allow the API server to only serve requests when it can verify the signature and expiration time in the JWT token and refuse them when it fails the verification.
Once the secret used by the Mobile App Attestation service is not known by the mobile app, is not possible to reverse engineer it at run-time even when the App is tampered, running in a rooted device or communicating over a connection that is being the target of a Man in the Middle Attack.
The Mobile App Attestation service already exists as a SAAS solution at Approov(I work here) that provides SDKs for several platforms, including iOS, Android, React Native and others. The integration will also need a small check in the API server code to verify the JWT token issued by the cloud service. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny.
SUMMARY
In the end, the solution to use in order to protect your API server must be chosen in accordance with the value of what you are trying to protect and the legal requirements for that type of data, like the GDPR regulations in Europe.
DO YOU WANT TO GO THE EXTRA MILE?
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.

Signing HTML Documents Using PGP or SSL via Web Forms

Let’s say I have a contract between two parties published on the Web. I want both parties to be able to sign the contract to show they consent to the terms, the way they would with handwriting in real life. I have seen many TOS agreements online where this is done with just a check box, but I want to go a step further and enable each party to assert that the signature is theirs and not a forgery (somebody else checking the box for them).
Assuming the page is already served via HTTPS and username/password combos are not an option, which cryptographic technology is best suited for identity validation: PGP, SSL, or something else?
How might I do this using only HTML and a LAMP server on the other end, in such a way that the process is as automated as possible while still being secure? Code samples are obviously welcome but not necessary; I’m just trying to conceptualize it: do the contents of the contract have to be included in the signature? Do I have the users upload public keys or something? I’m no crypto expert so that’s where I get lost.
SSL is a transport security mechanism, it's not applicable.
You can use OpenPGP or you can use PKI (X.509 certificates and CMS format). These technologies let you sign the data twice or more times without invalidating previous signatures - this is done by using detached signatures.
The choice of what (PGP or PKI) to use is yours - these technologies can be used in similar scenarios, but have different ways to authenticate keys: in PGP user keys are signed by other users, while in PKI certificates are signed by certificate authorities, which is supposed to have more credibility.
When you "sign the document" using cryptographic signature, from technical point of view it's a hash of the document that is signed. The hash can be calculated on the server and sent to the client for signing, then the detached signature is transferred back to the server. So you can keep the document on the server, and private keys used for signing will not leave the client.
However, to do actual signing on the client, you need some module which will communicate with the server and do the job. You can't go with just a web browser - some browser plug-in is required. The reason is that Javascript "cryptography", even if it technically allowed access to client-side keys stored in files or on cryptographic devices, has certain conceptual flaws which make it almost useless. So you end up with using something more trusted and secure, i.e. signed applet or ActiveX control or Flash script.
Our company provides various security components, among which there are components and modules for distributed signing (including above mentioned plugins). These modules are for PKI operations (though in general we also have components for OpenPGP operations, these components don't support distributed signing at the moment).
And I should note, that "automation" here is possible to extent when the user chooses the certificate to use and clicks "sign" button (for example). You can't sign anything without user's explicit action. In some cases the user would also need to provide a PIN / password which protects a private key from being misused.

Connecting iPhone app to a secure RESTful API?

I am building a RESTful API in Python with the Pylons framework, serving it with Apache2 and mod_wsgi, and would like to connect it to an iPhone app. I have very little experience with HTTPS, SSL, and certificate authorities, and I am wondering how I would go about securing my API.
How do I make sure that the API is being served through HTTPS? Is it necessary to, as in this example, set up an SSL certificate? If I sign an SSL certificate through an authority not recognized by iOS (CACert.org, for example, and mainly because it is free), will that affect my app's ability to communicate with my server? How have others solved this problem of securing communications between a web-based RESTful API and iPhone apps?
Also, how does OAuth fit into all this?
This really depends on what you mean by "securing" your API.
Do you mean that you want to A) secure it so that unauthorized people are unable to access the API or B) do you mean that you want some level of encryption on the data passed back and forth between the client and server?
If the answer is B or both, then you will definitely need to look at getting an SSL certificate and installing it on the server. Most certificate authorities have guides on how to do this.
I'm not sure what you mean by "an authority not recognized by iOS" but you should still probably consider forking out the dough for a certificate from a recognized authority. It still wouldn't hurt to try CACert.org though if they are offering free certificates. I can't really see there being any problem in terms of the ability of communication between server and client being affected.
In terms of securing your API from unauthorized clients, you could check out OAuth (see http://oauth.net/). There are various Python libraries for OAuth. Check out https://github.com/simplegeo/python-oauth2 for example. The only thing you may want to consider is that there is a reasonable learning curve when it comes to implementing OAuth.
The second link above demonstrates a simple OAuth client and also has example code for a three-legged authentication process.
You can handle certificates programmatically in iOS. You can even use self-signed certificates as long as your code acknowledges the fingerprint. I can't remember the details off the top of my head, but I know you can use didReceiveAuthenticationChallenge to do this.
In the long run, it is simpler to just buy a cert (cacert.org won't do).

How to securely communicate with server?

I'm building a solution consisting of an app and a server. Server provides some methods (json) and the app uses them. My aim is to make those API methods inaccessible to other clients. What is the best way to do so?
Should I take a look at certificates (to sign every outgoing request)? If yes, where do I start and what is the performance impact of doing so?
What are alternatives?
Put another way, you need a way to distinguish a valid client's request from an invalid client's request. That means the client needs to present credentials that demonstrate the request comes from a valid source.
SSL certificates are an excellent way to assert identity that can be validated. The validity of an SSL certificate can be confirmed if the certificate contains a valid signature created by another certificate known to be secure, a root cert. As noted in other answers an embedded certificate won't do the job because that certificate can be compromised by dissecting the app. Once it is compromised, you can't accept any requests presenting it, locking out all your users.
Instead of one embedded app cert, you need to issue a separate certificate to each valid user. To do that, you need to set up (or outsource to) a Certificate Authority and issue individual, signed certificates to valid clients. Some of these certificate will be compromised by the user -- either because they were hacked, careless or intentionally trying to defraud your service. You'll need to watch for these stolen certificates, place them on a certificate revocation list (CRL) and refuse service to these compromised certificates. Any web server is able to refuse a connection based on a CRL.
This doesn't solve the security issues, it just moves them out of the app. It is still possible for someone to create what appears to be a valid certificate through social engineering or by stealing your root certificate and manufacturing new signed certificates. (These are problems all PKI providers face.)
There will be a performance hit. How much of a hit depends on the number of requests from the app. The iPhone NSURLConnection class provides support for SSL client certificates and client certificates can be installed in the phone from an e-mail or authenticated web request. Managing the infrastructure to support the client certs will require more effort than coding it into the app.
Incidentally, voting down any answer you don't like creates a chilling effect in the community. You're not nearly as likely to get advice -- good or bad -- if you're going to take a whack at everyone's reputation score.
I will now freely admit that it's an interesting question, but I have no idea how it could be done.
Original answer:
Interesting question. Assuming people can't reverse-engineer the iPhone app, the only solution that comes to mind would be to sign requests with a public key, or some other secret known only to the application. By that, I mean adding an extra argument to every API call that is a hash of the destination URL and other arguments combined with a secret known only to your server and application.
To expand upon this: suppose your API call has arguments foo, bar and qux. I would add a signature argument, the value of which could be something as simple as sorting the other arguments by name, concatenating them with their values, adding a secret, and hashing the lot. Then on the server side, I would do the same thing (excepting the signature argument) and check that the hash matches the one we were given in the request.
Consider authenticated HTTP.
For a cheaper alternative, there's shared secret/hash scheme. The client and the server have a shared secret string of text. Upon request, the client hashes together (using MD5, or SHA1, or SHA something else - you choose) the request fields and the secret. The hash value is attached to the request - say, as another POST field.
The server does the same operation with the request and with its copy of the secret, then compares the hash values. If they don't match - service denied.
For added security, you may encrypt the hash with a RSA public key. The client has the public key, the server keeps the private key. The server decrypts the hash with the private key, then the same. I did that with a C++ WinMobile client and a PHP-based service - works like a charm. No experience with crypto on iPhone, though.
UPDATE: now that I think of it, if we assume that the attacker has complete control over the client (ahem jailbroken iPhone and a debugger), the problem, as formulated above, is not solvable in theory. After all, the attacker might use your bits to access the service. Reverse-engineer the executable, find the relevant functions and call them with desired data. Build some global state, if necessary. Alternatively, they can automate your UI, screen scraper style. Such is the sad state of affairs.