I have a JavaCard applet working on Gemalto SIM card in a smartphone. I would like to create an electronic wallet with validity to a specifed date and time.
I know this is impossible using a classic smartcard, which has no clock inside because of absence of the battery. However, with a SIM card it might be possible: a SIM card must have some access to network time (not the local system time, which can be changed by the user) when connected to the network and the last known network time value could be probably stored somewhere on the SIM card.
Is there any way to access the last known network time from my applet in a secure way? (I do not trust any application installed in the phone, because it could be easily hacked)
Do you think there is any other solution of my problem?
EDIT
I did not mention the reason why I think about this: I need to solve this problem without the Internet connection, because my customers are supposed to use my electronic wallet without the Internet connection in their phones. They need to use it in subway where there is no signal and some of them do not pay for the Internet connection at all. So my application must be able to find out the time offline.
EDIT 2
On Android phones, there is an option:
That means there is some user-independent source of time. The question is, if it can be accessed somehow in a secure way from a JavaCard applet on the SIM card. (or if the last known value can be accessed in the case of no connection)
It depends on your project. You have 3 solutions. one is for cases that you have access to Internet on the phone and two for cases you don't.
If you have Internet access :
In the phone application installation step, it sends the IMSI of the SIM card to a server that you established already via a https channel(Optional!).
Your server records that IMSI and the date of installation in a database table in the server.
Henceforth, each time that the phone application want to start a session with the SIM applet, it must send a request to your server and the server respond that request with an encrypted(its current date+IMSI_counter).
If the phone application receive the answer successfully sends it and the time of phone (in plain) to the SIM applet.
The SIM applet encrypt the "plain phone date+IMSI+counter" itself with the same secret key that we used in server and then it compare the result with the value that its server sent to mobile phone.
If both are equal, that means that the time of the phone is the same time of your server.
Using the above procedure, in cases that you don't want the SIM applet to work anymore, you can send an invalid encrypted value in the respond of phone application requests.
If you don't have Internet access :
All SMS packets enveloped concatenated with current time of server but normally, the operator sends its packets to a special applet on the card. I mean the packets has a header that indicate the AID of its applet in the card. The SIM card analyze and decrypt this packet data and the body of it return to phone (For calls and SMS-s, and not for OTA envelopes).In this procedure the data (both encrypted and decrypted) are not shared on the SIM. So if you install an applet on the SIM, there is no way to gain those data (Including the network current time) and you must use one of the following options :
Request your network operator to send a time envelope to your applet (i.e. the header of the packet indicate your applet AID) every day and automatically. (Using this method you don't need to do anything in your phone application anymore)
or:
Using the network-time section of other SMS-s on the phone using your phone application. (Using this method you need to require the SMS sending/receiving reading/writing privilege from the phone in your phone app installation and you don't need to ask the operator to do anything special for you!)
Related
There's a way I can send a file to an android device (wich already has my app installed) without paring or the app making the pairing in the background? (Without user intervention)
In my country just few people have data plans in their phones, so I want to create some kind of "server" using a raspberry and a bluetooth dongle so everytime an user with my app it's inside my store, I can show them notifications (with images and text) using the bluetooth connection insted of their cellphone data. (To detect they are in my store I can use geofences or regular beacons)
BLE is not intended to send files with huge size, since it can maximally send 20 byte chunks of data at a time. I'll definately go for the standard Bluetooth protocol if you have a file consisting of a huge size.
The pairing notification depends on how the app has been developed. If you know the device address (MAC address as unique ID) of the remote device beforehand, then you can make a simple "if" statement that checks whether the device address of each discovered device equals the one you have defined. If yes, then you can establish a connection. As a result, the app will automatically establish a connection with the desired device.
I'm building an app that needs to report some information about outgoing SMS messages. As I understand that a single Android device can house a different SIM card at any point in time, is there a way to look at the mobile number of the SIM card that sent a particular SMS message?
My current approach to looking at the sent SMSes is via a ContentObserver to content://sms, and while I can retrieve info such as the sending date, the target number, and the message body, I can't find a column from the Cursor that contains the device's mobile number when that message was sent. I also don't mind taking a different approach.
There is no guaranteed solution to this problem because the phone number is not physically stored on all SIM-cards, or broadcasted from the network to the phone. This is especially true in some countries which requires physical address verification, with number assignment only happening afterwards. Phone number assignment happens on the network - and can be changed without changing the SIM card or device (e.g. this is how porting is supported). I know it is pain, but most likely the best solution is just to ask the user to enter his/her phone number once and store it.
I'm trying to figure out if this is even possible:
I'm interested in writing a simple game that could be played in a peer-to-peer setup, rather than having to go through some intermediary server. I was thinking of using something similar to how SMS works, but I don't know if those routines are accessible.
From what I understand, SMS is just a data packet with a specific structure, and on a certain port, that gets sent to a phone number as the unique identifier, rather than an IP Address. If that is the case, is it possible to use similar routines to what SMS uses in order to send messages to another phone, but in such a way that SMS will not pick it up, and if the app that would understand that packet is not running, then the data would just get ignored?
You can write Apps that send SMS and receive SMS. Some things to keep in mind:
SMS tend to be expensive, especially when compared to IP traffic.
The user must grant the permission to send and read SMS to the app. He probably won't do, beacuse he knows it's expensive.
Even if the users contract offers a SMS flat rate, providers may limit the actual number of SMS being sent or forbid automated, high-traffic usage.
SMS might be much slower than IP packets.
If a user tries to play with someone who hasn't installed the App, that poor person will have his SMS inbox flooded with those SMS.
So it's mostly a bad idea to use SMS for that purpose. Some alternatives if the users are close enouth to each other:
Use bluetooth.
Use Wifi (Most android phones won't allow ad-hoc connections, but some phones can act as acces points so that others can connect to it).
Maybe: Use NFC (only some of the newest phones have this, and I don't know if you can use NFC that way).
Use P2P over internet (which requires at least one provider to allow incoming connections on their network with a public IP, e.g. no internal NAT).
Use a server that handles the traffic between phones.
Suppose I want to run some program which requests too many permissions. For example, record from the microphone or read IMEI of my phone. However, there are no practical explanation why recording from the mic or IMEI number is needed for this particular application, except for data mining.
I want to try this app, but restrict its permissions. For example, if it reads IMEI, it should get random IMEI(but the same every time). If it tries to read the mic, it should get silence.
Some other interesting permissions:
Phonebook read/write access -
returns zero contacts, pretend that
write is OK, but actually do
nothing.
Send SMS - pretend that SMS
is sent, but do nothing.
Get list of
visible Wi-Fi networks - return zero
networks.
Obviously the tool should require a rooted phone. Are there any such tools?
You could download the Android SDK and use an emulator to test our the applications. You could then set info like your phone book and test out how the app is using that data.
There is a TISSA prototype application, but it is not released, yet. In CyanogenMod 7 there is a setting to revoke application permissions, but if the app expects the API to return something useful instead of failing, it will crash, it is still not faking data.
i just found the free LBE Privacy Guard for rooted phones. It pretends to protect sms, Internet access, contacts, Call Logs, Positioning, Phone ID, Phone Call and phone state.
I'm looking for some input on how to go about a problem I have. We have a device that has binary data that it needs to send out (they are mainly just symbols, but in a custom binary format) over ethernet. I need to intercept this data on the phone and display the symbols over google maps. I'm just wondering the best way to go about this, I have a few ideas but am not sure if they are possible or feasable:
Is it possible for the phone to connect directly to the device if the device had some sort of server running on it, then poll for new data? If so, what is the protocol needed to be able to direct connect like that?
Perhaps modify the device software to send data to the phone(s) in SMS data message format? Im not sure if it is possible for software to "spoof" an SMS to a phone when it is not a phone itself?
Have the device software upload all its binary data to a ftp/http server that is sitting out there somewhere, have the phone(s) connect to that server and poll for new data periodically?
I'm brand new to android development, basically all I want to do is grab this binary data from the device on my phone and parse/display it over google maps. How do any of those ideas sound, or is there a much easier way I am overlooking? Thanks!
Is it possible for the phone to
connect directly to the device if the
device had some sort of server running
on it, then poll for new data?
Possibly, if they are both on the same WiFi LAN.
If so, what is the protocol needed to
be able to direct connect like that?
You would have to ask the manufacturer of your device. We have no way to know.
Perhaps modify the device software to
send data to the phone(s) in SMS data
message format?
If it is a GSM phone or a CDMA phone, perhaps this would work.
Have the device software upload all
its binary data to a ftp/http server
that is sitting out there somewhere,
have the phone(s) connect to that
server and poll for new data
periodically?
This has the advantage of working with the device over 3G, as the phone and device do not have to be on the same network -- they both just have to be able to reach that server. With Android 2.2, you could also use C2DM to tickle the phone to let it know there is data to be picked up.
For connection type, you can choose between Bluetooth, WiFi or GPRS/3G. What's best for your case depends on how close is the device to the phone and what connection capabilities it have.
You must also decide how connection will be initiated - by phone or by device. The only reliable option for a server on the Android phone is Bluetooth. Wifi is restricted for opening server sockets, and GPRS/3G is carrier dependent. If the device runs a server, you can access it via WiFi if it's on the LAN or Internet, for GPRS/3G it has to be on Internet.
Once you choose these things, you're left with the choice for protocol, but it's a long way to it for an answer at that stage.