PayPal's 'pay by mobile' application does not use NFC. Instead, it generates and shows the code which can be read (and keyed) by cashier or POS scanner. I suggested this technology 3 years ago. It was wrong time and... wrong place.

Video from PayPal: 
http://bit.ly/L3KGwE
Video with my solution:
http://bit.ly/LgBvp6
iPhone app:
http://bit.ly/JNvCUR
Android app:
http://bit.ly/LU1DIl

Interesting article in SearchSecurity: "P2P encryption for mobile is not an technology endorsement, says PCI Council". So on the one hand, in their recent mobile payments guide for merchants, they present the P2PE as the only way to secure mobile payments. On the other hand, they say " We’re not endorsing specific technology here".  I am not sure I understand the point they are trying to make. 

Review of PCI mobile payments guidance for merchants:
http://bit.ly/JCOB4q
Article in SearchSecurity:
http://bit.ly/KRCjnU

PCI Security Standards Council just released "customized fact sheet" - guidance for merchants on how to securely implement mobile payments. According to this document called "Accepting Mobile Payments with a Smartphone or Tablet" (but for some reason referenced in press-release as "At a Glance: Mobile Payment Acceptance Security"), Point-to-Point Encryption solution -- validated and certified by P2PE QSA using recently launched PCI P2PE assessment program, and listed on PCI SSC website -- "may help you in your responsibilities under PCI DSS" and "leverages a mobile device’s display and communication functions to secure mobile payments". The only diagram in this document, which illustrates the architecture of mobile payment solution, shows P2PE solution provider accepting and processing merchant's mobile payment transactions.        

How to know whether your mobile phone is being tapped?
It is difficult if your phone is bugged with FlexiSpy. On Android phone, you can install Symantec Norton Mobile Security which claims to be able to remove the spyware. 
There is another popular mobile spy software called SpyMobile.
They support virtually any mobile OS - iPhone, Blackberry, Android, Windows Mobile and Symbian - which means they can be installed on almost any device. If this application is installed on your mobile phone, it is running in silent mode so there is no way to know whether your phone is bugged. 

However, this software should be somehow manually installed and initially configured on your phone, and there are "secret" default keystroke sequences that should be keyed in order to activate the management console. To check if SpyMobile is installed on your phone, you need to try these sequences. If nothing happens, you are lucky. If you see the SpyMobile login screen, you are not.
Windows Mobile and Symbian: #123456789*
Android: *12345#
iPhone: **54321
Blackberry: #10001* 

FlexiSpy: 
http://www.flexispy.com/ 
SpyMobile:
http://www.spymobile.biz/ 
Symantec Android.Flexispy: 
http://www.symantec.com/security_response/writeup.jsp?docid=2011-122006-4805-99&tabid=3 
Symantec Norton Mobile Security:
http://us.norton.com/mobile-security 
Mobile spyware review:
http://www.spyphonereview.com 
More information on signs of bugged phone:
http://www.makeuseof.com/tag/6-signs-cell-phone-tapped/ 

I would like to update you on most important topics that have been discussed during 2011 PCI SSC annual meeting in Scottsdale, Arizona.

P2PE

The most (and almost the only) important topic was, as everyone expected, P2PE (Point To Point Encryption).

Recently, just few days before the meeting, the Council released a big document which defines requirements for Hardware/Hardware P2PE.

“Hardware/Hardware” means that both encryption and decryption are being performed by hardware modules approved by FIPS 140-2 Level 3, PCI HSM or PCI PTS certification programs (normally - pinpad device at the client point and HSM appliance at the switch end).

The document and its outcomes have been widely discussed during the meeting, and here are several important points that I noticed:

·         Hardware P2PE, when implemented according to SSC requirements and properly certified, is supposed to significantly reduce the PCI DSS certification scope, meaning reducing the merchants PCI costs, particularly – may eliminate additional firewalls installations and quarterly penetration tests. Therefore, merchants are supposed to be financially stimulated to look for P2PE encryption solutions. Technical detail: This is applied mostly to Hardware encryption, also with pinpad content signed by the vendor in a way that it would be impossible to alternate it, which provides functionality of internal “firewall” isolating device middleware from the rest of merchant’s network.

·         Final release of the requirements and most important – test procedures – will be published in Q4, or by the end of 2011, which means that if you want to be the first in this race – the design and the code should be done by the end of this year.

·         There will be special certification program introduced for P2PE, auditors will have to be certified as “P2PE QSA” in order to be able to perform such assessments. The timeline for certification program finalization and QSA training – Q1 2012, but no one believes it is going to happen in Q1 and most probably it is going to be Q2 or even later.  I talked to several QSAs and all of them have no clue about the program details, even not all of them intend to be trained for it in near future. If you want to be in first wave of certified P2PE solutions, most probably, you will have to stick with the “big” guys as they are the only ones who commit for everything from SSC as soon as it comes to live.

·         Even though major focus is being made on Hardware/Hardware P2PE as almost ultimate solution for the PCI compliance, software P2PE will still remain a valid option. There is a plan to release detailed requirements regarding SW P2PE as the next step (though no timelines were provided). This will include definition of HW P2PE with SW key management.

PA-DSS

There is interesting tool provided by PCI SSC that allows you to determine whether application is eligible for PA-DSS assessment. This is simple questionnaire which is available online. If one of the answers is YES, the application should not go through the PA-DSS validation.

Please take a look – there are interesting questions.

For example, according to question #8, if the product is DLL that requires third party hosting application, such software might not be validated through PA-DSS while any POS that uses it should be certified either through PA-DSS or PCI DSS process.

Mobile

Currently, according to the guidelines recently released by the PCI SSC, most mobile payment applications do not qualify to be PA-DSS compliant. There will be a draft guidance on PA-DSS for Mobile devices released in Q4 2011.

ISA

There is interesting program for companies that want to perform their own internal PCI DSS like assessments – it is called ISA (Internal Security Assessor). The company that wants to participate just needs to enroll to this program and send people for training.

Links:

https://www.pcisecuritystandards.org/documents/nb59Y8Qqv/P2PE_Hardware_Solution_%20Requirements_Initial_Release.pdf
https://www.pcisecuritystandards.org/documents/Applications_Eligible_for_PA-DSS_Validation.pdf
https://www.pcisecuritystandards.org/documents/statement_110624_pcissc.pdf
https://www.pcisecuritystandards.org/training/isa_training.php

PCI Security Standards Council recently issued press release clarifying position of the Council on mobile payment applications. According to the special “update on PA-DSS and mobile payment acceptance applications”, PCI SSC won’t allow payment applications developed for mobile devices such as iPhone, BlackBerry, Android etc. to be accepted for PA-DSS validation which means that such products won't be able to achieve PCI PA-DSS compliance and therefore used as part of merchant’s PCI DSS compliant environment. This limitation won’t affect applications developed for special devices intended especially for payment processing. PCI SSC does not specify such devices so it is unclear who and how is supposed to classify the hardware and determine whether it is eligible for validation. The Council also promised to further clarify the situation with mobile payments and “produce additional guidance by the end of the year”.
It should be still possible to avoid an issue with the validation of mobile payment application if software installed on mobile device does not store or process sensitive card data because in this case the application would not fall into the definition of payment application as described in PA-DSS, and therefore is not required not pass the validation at all.

Using your mobile phone as a token generator for two-factor authentication is becoming de-facto standard and common solution used by major companies operating online for extra protection of user accounts from unauthorized access. Such services are provided for free which is not the case with hardware token products like RSA SecurID and VeriSign VIP. In fact, software solutions also use device, which is your mobile phone, but since this is your phone and they do not have to produce and supply to you any special hardware - such services require no additional costs and therefore can be provided for free.  
What is two-factor (or two-step) authentication? It combines two factors (from maximum three available factor types according to the security theory): something you know (such as  username/password or pin code) with something you have (magnetic or smart card, token key, or mobile phone). Third possible factor is something you  are which is biometrics.
There are three major methods of two-factor implementation used by online service providers: hardware tokens, SMS, and smart phone application (software) tokens. Hardware tokens are usually offered for money and therefore less common than SMS or software tokens. Also, major hardware token solution RSA SecurID has been recently compromised which even increased the motivation for using software solutions.
Many online service providers implement two-factor combined from username/password (first factor) and mobile phone (second factor) which provides relatively high security level comparing to traditional single factor authentication (username/password only).
Some giants such as Facebook and Bank of America offer only SMS solutions for mobile phones. One-time token (6 digit number) is generated by the server and sent to user’s mobile phone as SMS text. Other companies such as PayPal provides SMS service as well as more convenient smart phone app (also used by eBay). In latter case VeriSign VIP software installed on iPhone, Android or other smart phone device generates new one-time token code (the same 6 digits) every minute. The advantage of software solutions is that they do not require any communication between mobile device and server which completely eliminates data transfer or text message fees.
Google offers even more options - application tokens, SMS and also voice messages.
Regardless the particular implementation, any form of two-factor authentication provides higher level of security and makes your account significantly less desirable target for hackers comparing to regular accounts protected by just user/password.

I downloaded and installed Opera Mini on my iPhone a few days ago. At a glance, it looked very impressive: tabs like in "real" browser, start page with convenient shortcut icons, and finally most important - double speed if you compare it to Safari. But what is a price of such performance, if any? After brief research I found out that there is a cost for increased speed: security. Opera improves the browsing speed by preloading the web pages to their servers, compressing and encoding them and then sending the compressed stream to the iPhone client which decompresses and decoding them in order to show to the user. As cellular communication is still a bottleneck, such approach dramatically improves the speed. However, when traffic is encrypted with SSL, it must be decrypted by the Opera server and then re-encrypted again in order to be compressed and encoded, which means that there is no true end-to-end encryption anymore, and if someone breaks into the Opera data center, the sensitive data will be compromised. On the other hand, since it always encrypts the traffic between the browser client application and the Opera software server, the regular website browsing is more secure than one performed by Safari! The bottom line: for maximum security, browse regular websites with Opera, but use Safari for https protected places, especially for financial and payment applications such as online banking and PayPal. Since most of financial institutions provide their own apps for iPhone, the Opera Mini browser for iPhone still has a good chance to compete with Safari.