Googlemail integration for encrypting, decrypting or signing emails.

GPG4Browsers is a prototype implementation of the OpenPGP Message Format [RFC 4880]. The implementation is currently written as Chrome Browser Extension with a Googlemail integration for encrypting, decrypting or signing emails.

The OpenPGP implementation supports all asymmetric, symmetric ciphers (except IDEA) and hash functions specified in the standard and implements the following use cases:

• Encryption and decryption of messages
• Sign and verify message signatures
• Import and export of certificates

The implementation is compatible with the GnuPG implementation standard settings except the standard compression used. To create a compatible message in GnuPG use the option --compress-algo none.

Limitations and Licensing

The code is released under the GNU Lesser Public License.

The implementation currently not supports:

• Generation, manipulation or creation of signatures on keys
• Several signature types on keys
• Symmetric only encrypted messages
• Compressed data packets

Contributions

The following code of other projects has been modified or used for this project:

Component	Contributor
AES library	Herbert Hanewinkel
CAST5 library	pjacobs@xeekr.com with modifications from Herbert Hanewinkel
DES library	Paul Tero with modification from Michael Hayworth
Blowfish library	nklein software (Patrick Fleckenstein)
Twofish library	Atsushi Oka
SHA library	Brian Turek
MD5 library	Henri Torgemane
RIPEMD/160	Derek Buitenhuis
Base64 encoding library	Herbert Hanewinkel
JS BigNum library	Tom Wu
OpenPGP CFB	Partially from Herbert Hanewinkel
UI library	The jQuery Project

Get the code

The current release is available as ZIP archive here.

The source code is located in the following subversion repository:http://gpg4browsers.recurity.com/svn/gpg4browsers/

Install

To install the extension perform the following steps:

• Get the source code
• Open chrome://extensions in the google-chrome browser
• Enable the developer mode on the far right
• Click on "Load unpacked extension .." and select the source code folder where the manifest file is located
• Check the "Allow in incognito" option.

Setup

For using the Browser extension you need to import private and public OpenPGP keys. This can be done by using the extensions options page linked at chrome://extensions. The options page allows to search keys on a public key server which exposes the service at port 80.

Usage

• Login to google mail
• Click on the page action (on the right side of the address bar within your google mail tab) to create a openpgp message
• When an OpenPGP signed or encrypted message is displayed in the google mail interface a popup occurs allowing the mail to be opened with GPG4Browsers.

Documentation

The source code is documented using JavaDoc annotation. An architectural overview as well as example code can be found in the Developer Documentation (PDF).

Source : http://gpg4browsers.recurity.com/

IPv6 Wireless Internet IniTiative – 6WINIT

The 6WINIT project investigated the problems in introducing a range of IPv6-enabled applications over an IPv6-enabled wireless Internet. It covered the areas of end-stations, routers, gateways, generic technologies and applications – with specific emphasis on following the IPv6-related standards emerging in the IETF. Thus Mobile IP, Road Warrior technology, Quality of Service,
agent technology,  interworking across WLAN, GPRS and UMTS,  and security were of particular concern. Generic applications investigated included conferencing, voice over IP, video streaming, location-based services and home environments. There was specific emphasis on clinical applications, where secure mobile access was demonstrated to clinical data and radiographic images, and emergency treatment from ambulances for Accident and Emergency. Most of the work was in the context of Wireless LANs, since the access to and functionality of GPRS were very limited and the access to UMTS test facilities was provided only at the project end; nevertheless, experiments were carried out both with GPRS and UMTS test facilities.
Objectives:
The principal objective of the 6WINIT project was to validate the introduction of a new mobile wireless Internet in Europe - based on a combination of the new Internet Protocol version 6 (IPv6) and the new wireless protocols used in WLAN, GPRS and UMTS/3GPP networks.
Technical Approach:
The basic network components used in the project were a combination of IPv6 and wireless networks. The project provided an insight into the problems in deploying real applications in the emerging IPv6-enabled wireless-enabled  Internet; WLAN, GPRS and a UMTS test cell were used as wireless networks. We carried through complete systems pilots, and identified what components are inadequate in the applications, network facilities, major components and middleware. The project concentrated on mobile and wireless aspects of the system, but it also linked into the existing IPv6 wired infrastructures provided under the 6NET and Euro6IX projects. The technical approach was to take applications from other activities, which were expected to gain from the mobile IPv6 environment. These applications, which were  mainly selected from the clinical health care, multimedia conferencing and streaming, in- and outdoors navigation and home control domains, were ported to work over IPv6. This way we ensured that all the requisite technology was available to allow them to work in a wireless-enabled IPv6 environment.
Consequently we were also working on IPv6-enabled components: routers, relays, hand-helds, IPv4 to IPv6 transition mechanisms and other software components required by the applications. Because of the limited capability of the GPRS network, some of the traffic had to be run, in that case, in IPv6/IPv4 encapsulation.
We carried out many experiments with GPRS, UMTS and WLAN networks – together with the appropriate applications. For example our work with GPRS showed that the latency was both much too long for interactive conferencing, had much too much short-term variation in its value, and much too low a bandwidth. Other experiments showed that it was possible to use PDAs with the wireless connectivity for getting reasonable resolution of cardiac images. Another showed that in our hospital settings, the WLAN radiation had no discernable impact on the clinical instrumentation – though some of the instrumentation had occasional impact on the WLAN operation (e.g. during MMR scans or anti-coagulator action). We also investigated the precision we could obtain on location sensing indoors, using WLAN technology, and on the rate of handoffs achievable with the WLAN. Finally we showed that one could have fast multi-access handover between the UMTS test-cell and WLAN.
Applications:
A wide variety of IPv6-enabled applications were pursued – infrastructure (e.g. Mobile IP, Road Warrior, etc), generic (e.g. Voice over IPv6, Media streaming, Secure remote control of the home environment, etc) and clinical (e.g. Access to clinical data bases, consultation with moving ambulances, etc).
Results:
Our results are fully reported on the 6winit web store  http://www.6winit.org/. However a significant number of components and features are expected to be developed further – often in a commercial setting (e.g. The Guardian Angel System, Router components for mobile IP, Highquality streaming, etc).
Innovation:
Many of these results are highly innovative. An example of the integration of many of the results together are illustrated in a demonstration given in the final review.
A simulated ambulance professionals communicate via a mobile terminal, capable of providing voice, video and data on body parameters from a patient like electro-cardiograms and blood pressure, communicate via both a UMTS test cell and a wireless LAN with other professionals in a simulated hospital. The communication uses Mobile IP and simultaneous multi-access, with secured data transmission based on a Public Key Infrastructure.
Contribution to Standards:
During course of this work there were many contributions to the standards for Mobile IP, simultaneous multi-access, IP security, SIP, multimedia transport and IPv6/IPv4 transition. Almost all these contributions were made to the Internet Engineering Task Force.
Success stories:
As a result of this work, an excellent set of IPv6-enabled components and applications became available both to show that IPv6 was becoming a viable technology, and that wireless-based IPv6 applications could be built. Specifics of the results are being incorporated into the products of the 6WINIT partners; examples are the router components. Others are being used to be the core of new business ventures; an example is the GANS system. Yet others are being used to persuade the regulatory authorities to allow the systems to be used in the hospital environment with real patients; an example is the database access system. Of particular importance is that the wealth of IPv6 applications developed are an important input to two large IPv6 deployment projects 6NET and Euro6IX, and have provided important inputs to many new projects.
The applications developed in the project (6VOICE, GANS, streaming etc) are being used in multiple follow-on projects for further features.
Project name:
6WINIT - IPv6 Wireless Internet IniTiative
Contract no.:
IST-2000-25153
Project type:
RTD
Start date:
01/01/2001
Duration:
25 months
Total budget:
€ 6,018,800
Funding from the EC:
€3,492,000
Total effort in person-months:
550
Website:
http://www.6winit.org/
Contact person:
Prof. Peter T. Kirstein
email: Kirstein@cs.ucl.ac.uk
tel.: +44 (0) 20 7679 7286
fax: +44(0) 20 7387 1397
Project participants:
6WIND   F
BT   UK
Ericsson-Poland PL
Ericsson-Research SE
ETRI   KR
IABG   DE
RUS   DE
T-NOVA  DE
TED   DK
Telscom  CH
TZI   DE
UCL   UK
UKT   DE
UMM   PL
UoS   UK
VTT   FI
Keywords:
IPv6, wireless, applications, testbeds and mobile.
Collaboration with other EC funded projects:  5
6INIT
6LINK
6NET
ANDROID
NGNI
WINE
IST - Research Networking - Research on Networks – IPv6

Source : ftp://ftp.cordis.europa.eu/pub/ist/docs/rn/6winit.pdf

IPV6 security

One of the first problems facing any layer three protocol is address resolution. Given an IP packet, how to deliver that to an Ethernet interface?

IPv6 uses a protocol called the Neighbor Discovery Protocol (NDP) to do address resolution, among other things. Neighbor Discovery (ND) uses multicast to a small set of similar addresses rather than a broadcast to all, but in broad terms is very similar to IPv4's ARP. The router builds a cache of layer three to layer two mappings. For new destination IPv6 addresses the router sets up a new cache entry, sends out an ND solicitation, and waits for the desired host to respond with its layer two address. If the router receives no response within a certain time, it discards the cache entry; otherwise it completes the cache entry and can then use it to deliver packets to that destination IPv6 address.

If someone sends lots of packets for non-existent IPv6 addresses, the router will end up with lots of incomplete cache entries. If enough such packets are received fast enough, all available cache slots may be used up, meaning that no new addresses can be reached. Since completed cache entries time out after a little while, even good entries may be dropped, to be replaced by new never-to-be-completed entries. Unlike most other NDP-related attacks, this one can come from outside your network. It doesn't take much bandwidth either – timing out an incomplete cache entry takes about four seconds; in four seconds a gigabit link can deliver more than enough packets to be a problem.

Sadly there is no real defence yet. Bad packets are indistinguishable from good packets; the router can't tell that an address doesn't exist unless it does neighbor discovery on it. The simple defence of having a big enough cache to handle the load is not feasible with IPv6, where just a single subnet has billions of possible addresses. You can mitigate the problem by doing things like using small subnets, filtering packets at your border, rate limiting and so forth, but the real defence lies in sophisticated cache management in the routers.

Another NDP issue is rogue router advertisements. Setting up an IPv6 “router” is trivial on any modern desktop or laptop. An on-link host sending unwanted router advertisements can cause havoc – deprecating prefixes, redirecting traffic and so on.

There are two solutions in the wings, but neither is complete or robust yet. The first is Secure Neighbor Discovery, or SEND. SEND uses cryptographically generated addresses and signed NDP messages, guaranteeing that the apparent sender of an NDP message is in fact the sender. Combined with a mechanism for distributing certificates (a PKI), SEND is a solution to rogue RAs; without a PKI, it is not. SEND is a moderately heavyweight solution, but a bigger issue is that neither Windows nor OSX currently support SEND.

A second solution is RA-Guard. RA-Guard is (conceptually) a piece of software that sits at a security border such as a switch, and inspects passing RA messages. If they meet certain criteria, RA-Guard lets them pass. If they do not, RA-Guard blocks them. This sounds simple enough, but it turns out that IPv6 throws a few curve balls – current implementations get confused by extension headers, for example. Fixing this means either redefining the NDP protocol to forbid extension headers, or building lots of wire-speed layer three smarts into switches.

Thanks to : Karl Auer

Source : http://www.cso.com.au/article/403624/ipv6_security_everything_old_new_again/

IPV6 : a big win for school

Cyberbullying may be more of an operational issue in schools than the outside hacking that enterprises face, but opaque IPv4 network configurations are causing security issues for both groups as organisations struggle to enforce administrative policies by reliably matching IP addresses and user identities.

Such was the experience of StudentNet, a specialist educational IT consultancy that recently worked with two of its school clients and called on groups of students to participate in a World IPv6 Day "torture test" of the successor to the ubiquitous and capacity-challenged protocol upon which the Internet is based.

Waverley College – a year 5-12 school in Waverley in Sydney's eastern suburbs – and Wollondilly Anglican College, on the south-western fringe of metropolitan Sydney, presented two very different network administration environments but had two similar objectives: to improve visibility of and control over their students' online activities.

Differences in their networks, however, made this difficult. Waverley College, in particular, was configured in a dual-NAT (network address translation) configuration in which the college and its ISP were each running separate NAT domains. This provided a double buffer hiding students' IP addresses from the Internet at large, but it also meant the school had no way of easily resolving the identity of a network user who was alleged to be the source of cyber harassment.

Add in the sheer size of schools – typically from 1000 to 1800 students – and demands on the network scale rapidly. With hundreds of students simultaneously using rich media sources that burden the network and create massive volumes of sessions, traditional network architectures can become buried in a sea of anonymity. "Intrusive" proxy servers – which provide Internet filtering and content buffering – don't help either, since they can complicate the logging of user sessions and activities.

"Private schools in particular are very isolated from each other," StudentNet business manager Kevin Karp told attendees at the recent IPv6 Summit in Melbourne. "They have to deal with unexpected complexities and complications because of the community they're dealing with. It's very different to an SMB or large enterprise, because school education has to do with large blocks of data done on a very repetitive basis and done with a large number of students."

Because it does away with NAT and allows addresses to be assigned in meaningful groups, IPv6 offers a significant improvement, Karp said: for example, the protocol would allow a school administrator to give students IP addresses grouped into blocks by year level. These could then be used to enforce year-appropriate content filtering, learning management system access, YouTube access and other policies with a clear correlation between the address and the person logged into the system.

"The advantage of being able to undertake individual IP addresses for each student is that you know the student is in Year 10, say, instead of Year 6. You can protect the Year 6 kids a lot more because with IPv6 they're all on the same IP address range" rather than relying on whichever address the NAT spits out on a particular day."

As well as providing better control and role-based segregation of network users, IPv6 provides visibility that's lacking under current NAT-based IPv4 structures. Such capabilities are invaluable in forensic activities such as tracking down cyber-bullies, but they're also important in helping the network reach out to better manage the influx of mobile devices.

"We've got this mushrooming of mobility, computer usage and network size that introduces complications all through the school's operations," said Karp. "Establishing the identity of the students – especially if they're somewhere else and not at the school – is more difficult because of NAT, which is introducing an identity problem that's very difficult to deal with."

The World IPv6 Day tests got off to a rocky start when a simultaneous ISP failure saw gathered dignitaries faced with no connectivity at all. But once the problem was identified and the ISP came back online, the IPv6 environment worked as expected and Karp said the day was labelled a massive success.

Reinforcing the value of minimising NAT presence, Karp said, administrators at Wollondilly Anglican College had only its own NAT to deal with, and not an additional layer of obfuscation at its ISP as at Waverley. The IPv6 layer worked smoothly during the World IPv6 Day test, with students simply getting online and getting on with things.

Thanks to : http://www.cso.com.au/article/405226/ipv6_boosts_schools_on-net_security/

Boost to IPV6

Support for IPv6 has grown by almost 20 times in the past year by one measure, but most websites still can't be reached without IPv4, the current Internet Protocol, which is near running out of unclaimed addresses.

The number of subdomains under .com, .net and .org that support Internet Protocol version 6 increased by about 1,900 percent in the year leading up to October 2011, according to an automated sampling of subdomains by Measurement Factory. The study, which was sponsored by IPv6 software specialist InfoBlox, used a script to automatically sample 1 percent of the subdomains under the three well-known top-level domains.

IPv4 only allows for about 4 billion addresses, whereas IPv6 has a nearly unlimited supply. ICANN (Internet Corporation for Assigned Names and Numbers), the global governing body for the Internet,assigned the last of the unclaimed IPv4 addresses to regional registry bodies earlier this year. Some enterprises and service providers are making a gradual transition to IPv6 using dual software stacks, but experts expect users eventually to come to the Internet without IPv4 addresses. They will need pure IPv6 communication, which most operators of websites can't offer today.

Last month, 25.4 percent of subdomains under .com, .net and .org supported IPv6, up from just 1.27 percent a year earlier. However, the long-awaited IPv6 future may not be as close as it sounds from that statistic.

All the figure means is that a DNS (Domain Name System) server can point to those subdomains using IPv6. If a user with an IPv6-only device tries to go to a website, for example, the site's registrar can match up its URL with an IPv6 address and kick back an answer to the Web surfer, said Cricket Liu, vice president of architecture at InfoBlox.

Most of the dramatic boost in the past year came when GoDaddy, one of the world's largest domain registrars, made its DNS work with IPv6. GoDaddy claims its DNS service has more than 30 million customers. Had it not been for GoDaddy, the number of subdomains supported would have grown by a bit more than double, to about 3 percent, according to Measurement Factory.

But for now, most of those DNS requests wouldn't take an IPv6-only user to an actual Web page, because less than 1 percent of all subdomains surveyed had IPv6-enabled Web servers, according to the Measurement Factory study. Likewise, there were very few IPv6 email servers. Just over 2 percent of zones were served by IPv6-compatible mail servers.

The good news is that many more operators of websites, such as GoDaddy's customers, now can serve IPv6 visitors once they have an IPv6-compliant Web server, Liu said. Along with GoDaddy, Measurement Factory cited three other major registrars, Gandi and OVH in France and Active24 in the Czech Republic, that adopted IPv6 during the period.

GoDaddy has said it plans to extend its IPv6 strategy soon by supporting the new protocol on its website hosting service. Then, companies that rely on GoDaddy instead of operating their own Web servers will be able to run an IPv6 site.

The study found France leading in IPv6 adoption, with 57 percent of subdomains in France reachable by IPv6, followed by the U.S. with 42 percent and Czech Republic with 36 percent. But its scope was limited by examining only .com, .net and .org. For one thing, that left out subdomains that are under country-level domains in Asia, where a more severe shortage of IPv4 addresses has led to strong government efforts behind IPv6 in some countries.

The sample also overlooked other top-level domains where IPv6 has been more widely adopted, such as the .gov domain of the U.S. government and the .edu domain used by universities, said Nav Chander, an Internet infrastructure analyst at IDC. However, the move to pure IPv6 networking remains slow,

Thanks to : http://www.cso.com.au/article/408200/boost_ipv6_use_only_one_step_solution/

IPV6 : more secured

So although IPSec is a mandatory part of IPv6, it's not mandatory to use it. It's nice to have seat belts, and having seat belts built in does make it more likely people will use them. We've been using IPSec for years in IPv4, mostly in VPNs. IPSec was invented for IPv6 and then retrofitted to IPv4, so it is no wonder the mechanics are so similar. IPv6 uses two extension headers (rather than header options) to support IPSec. The Authentication Header (AH) provides authentication and integrity. An integrity check value (ICV) is calculated over the packet and the result is inserted into the packet as an extension header. The recipient calculates the ICV, and if the received ICV matches the calculated ICV, the recipient knows the message comes from the address that appears to have sent it, it was not altered in transit. However, nothing is hidden — the packet is not encrypted. Because the source and destination addresses are included in the ICV calculation, AH cannot pass network address translation (NAT). The Encapsulating Security Payload (ESP) header encrypts payloads, hiding them from prying eyes while in transit. The payloads are not transmitted; they are replaced by ESP headers. The ESP header does ensure the integrity of the payload, but it doesn't guarantee the integrity of anything else, such as the source and destination addresses, or any other headers that may accompany the packet. The solution? Use both types of header: ESP to encrypt the payload and AH to ensure the integrity of the entire packet. Internet Control Message Protocol (ICMP) Many IPv4 network managers block all ICMP. It is a simple and effective way to protect against various attacks. While most well-managed networks are not quit so heavy-handed, it is still quite a common approach. But it's an approach that does not work very well with IPv6. IPv6 uses ICMPv6 to do critical things like neighbour discovery. Blocking ICMPv6 on an internal interface will interfere with these things. Blocking it on an outside interface, at the border of a network will have a more subtle effect — it will break path MTU discovery (PMTUD). IPv6 fragments packets only at the source, and reassembles them only at the destination. Fragmentation is done at the edges of the network, making the core faster and more efficient. When a router discovers that it cannot forward a packet because it is too large for the outgoing interface, the router sends an ICMPv6 “packet too big” response back to the source, giving the maximum transmission unit (MTU) that it can support. The source node tries again with that MTU. This is repeated until a packet size is found that is small enough to make it through all intervening routers to the destination. If anyone along the way is blocking ICMPv6, packets will be dropped, and the sender will have no reason to try smaller packets. By all means block those ICMPv6 types that you don't need — router advertisements on an outside interface, for example. And by all means rate limit those that might otherwise pose a risk — echo requests, perhaps. But block with care! If you are providing a service that may be affected by other people breaking PMTUD, such as a website, consider setting your outgoing MTU to 1280 - the minimum size that IPv6 supports. You will lose some efficiency, but will be immune to PMTUD failures.

Thanks to : Karl Auer
Source : http://www.cso.com.au/article/406672/ipv6_click_clack_front_back/?fp=4&fpid=959105

Freescale Introduces 'Home Health Hub'

Freescale Semiconductor has introduced a home health hub (HHH) reference platform to help medical equipment manufacturers quickly and easily create remote-access devices that can collect, connect and securely share health data for improved healthcare management. The HHH reference platform is based on Freescale's i.MX28 applications processor and ZigBee® and sub-1 GHz transceivers. It enables secure WiFi and Ethernet connectivity to remote devices with displays, such as tablets, smartphones or PCs with medical-specific remote user interface (UI) options. The platform also can provide wired and wireless connectivity to end healthcare devices, such as blood pressure monitors, blood glucometers, weight scales, pulse oximeters and more via ZigBee, sub-1 GHz, USB, Bluetooth and Bluetooth Low Energy including medical-class-specific device profiles. According to the World Health Organization, there are 860 million chronic disease patients worldwide, and 75 to 85 percent of all healthcare spending can be attributed to chronic disease management. Many of those who suffer from chronic diseases are 65 years or older – a demographic that the U.S. Census Bureau estimates will represent 19 percent of the U.S. population, or about 72.1 million individuals, by 2030. Societies around the world continue to look for ways to reduce health care costs for these chronic patients while improving their quality of life. Remote patient monitoring devices can be made based on Freescale's home health hub reference platform and can allow patients to avoid unnecessary emergency room visits which both saves money and helps improve patient outcomes. "The changing dynamics of the aging global population are creating an increased demand for new technologies and tools that can offer peace of mind to the family members of seniors living at home," said Steven Dean, manager of Freescale's Global Healthcare team. "There's also a need to provide access to healthcare in remote and growing regions of the world to improve the quality of life for millions of people. Our new home health hub reference platform is designed to simplify development of connected medical devices and help our customers more easily address these growing needs." Freescale's HHH reference platform provides comprehensive functionality and can be used as the foundation for connected medical product designs, giving developers a head-start to help them get to market faster. The Freescale HHH reference platform delivers a hardware implementation and the necessary software components to provide pre-validated, secure connectivity for healthcare devices and user interfaces. "We have proven technology out there to monitor patients and connect their data to the cellular network, such that a healthcare professional could intervene instead of the patient having to go to the emergency room," said Kent Dicks, founder and CEO of MedApps. "We've found this to be extremely effective." The HHH reference platform software adheres to Continua device profiles to provide consistency and compatibility with other Continua-certified medical devices such as blood pressure monitors, pulse oximeters and weight scales. The platform also enables connection to the Microsoft HealthVault, a privacy- and security-enhanced online data repository that lets users organize, store and share their health information. The HHH reference platform consists of an aggregator/gateway board based on the low-power i.MX28 applications processor (built on the ARM9™ processor) running various connectivity interfaces to healthcare end devices and wireless or wired connectivity for a remote user interface. Also included is a panic alarm sensor based on Freescale's MC12311 sub-1 GHz radio, providing personal emergency response system (PERS) functionality. To complete the reference platform, software such as board support packages (Linux® and Windows® Embedded Compact 7) and example code are included. "If you think about all of the different devices in a healthcare ecosystem, Windows Embedded allows our partners to align on one trusted technology platform," said Lorraine Bardeen, marketing director for Windows Embedded EMEA at Microsoft. "This collaboration with Freescale builds upon Microsoft's vision for the evolution of intelligent systems by helping medical manufacturers and healthcare organizations capture the full potential of connected medical data." Pricing and availability The HHH reference platform consists of the aggregator/gateway board, panic alarm sensor, quick start guide, cables and software. Freescale has partnered with Digi International to bring the HHH reference platform to market. The iDigi Telehealth Application Kit is available for purchase through Digi International for $499 (USD) at www.digi.com/hhh. Digi has extensive experience with the i.MX portfolio and provides customized system on module and design services. For more information, visit www.freescale.com/homehealthhub.